Feature/100 crawling mcp solver

[plebania]

No description provided.

[mytkom]

I will do another review of algorithm/test code, I did some obvious comments for now to get these shallow things done.

[migoox]

For now mostly XRay related comments, I will look into the cpp code later

[migoox]

Since we are moving to presets I think it's not necessary

[mytkom]

I've given some ideas for improving readability of your code. Please, do not trust them too much, think of them and answer if in your opinion it is: a) possible to implement it this way b) wouldn't worsen the performance much.

[mytkom]

This struct will be unnecessary if we add those operator methods to the Read struct, but we would probably also need to compare the start index (and only if this is equal, we compare end indices), which will add additional overhead to your code.

So idk if this would be a positive change, we should discuss it with other team members---if it would be useful for them to have such operators available.

[mytkom]

Should be snake case, and be named differently. You are not printing reads, but the scheme of their mapping to the reference genome. This print would also lose sense if the reference genome length were longer than tens of bp. I wonder if we shouldn't add a new verbosity level for such methods, because -v flag (logging::DEBUG) can be quite useful for the user now, but adding your prints to it would totally destroy the readability of prints for real-world usage scenarios (~30k bp reference genome length).

I also wonder if it wouldn't be nice to create, let's call it, a decorator class, which will wrap the SOAPairedReads object and provide operator<< overload, which then could be used with LOG_WITH_LEVEL macro. I am not sure about the names, but it will look something like that:

LOG_WITH_LEVEL(logging::TEST) << BinarySchemeVisualizer(soa_paired_reads_object);

Then, on the level of the algorithm's code, you can see everything:

1. What is the verbosity level?
2. What object is being printed?
3. What is the format of the print?

[migoox]

I agree. We should avoid std::cout and friends in favor of logger, as we can control the verbosity levels via v flag as @mytkom explained

[migoox]

According to cpp-reference:

A function defined entirely inside a class/struct/union definition, whether it's a member function or a non-member friend function, is implicitly an inline function unless it is attached to a named module(since C++20).

so these inline specifiers are redundant in the SOAPairedReads

[migoox]

I agree. We should avoid std::cout and friends in favor of logger, as we can control the verbosity levels via v flag as @mytkom explained

[migoox]

I think that we can use the public inheritance here to allow polimorphic calls