Convergence issues with overlapping strategies

[sklbancor]

MUST BE MERGE INTO #606 ASAP

Overlapping strategies are designed to recreate Uniswap v3 like strategies on Carbon, ie ranges that trade bidirectional taking a small fee. Unsurprisingly -- in hindsight -- those strategies behave as badly within the Optimizer as other strategies with fees would (see #588). There is a reason that we ignore fees in the Optimizer and add them back only in the fine tuning step.

High level the solution is actually pretty easy: remove the effective fee component from overlapping strategies. The current PR is designed to achieve that. However, it is a bit hacky, and once we have time we need to also take into account a few considerations spelled out in the next comment

[sklbancor]

The current strategy dealing with effective fee removal for overlapping strategies works, but there are some issues that need to be address in the long run

• The optimal solution depends on the size of the fee (or bid/offer; the two are the same): the smaller the fee, the worse the Optimizer is affected, and the less impact on the overall solution it has to remove it; the bigger the fee, the more benign it is for the Optimizer (eg, 10% fee is definitely not a problem) and the worse it gets when we remove it; so we need to work on the threshold between removing the fee or not
• Where those adjustments are to be made is not clear; a priori that is a numerical issue that is better understood on the Optimizer / CPC side (and definitely not on the Node side); however, there are admin issues to consider as well, eg regarding CIDs
• In the long run, we should probably provide a Carbon strategy constructor that encapsulates the current Carbon order constructor because then the CPC has the information it needs to understand whether or not to make adjustments (at the moment it just sees different orders and it does not connect them); we discussed the issues around CIDs of this approach with Nick, and possibly the move to a CID / Sub CID approach
• Relatedly we noticed that the current CPC code creates curves that are optimized for the MargPOptimizer (notably, enforcing minimum curvature; the new code modifying strategies in place would fall into the same category); whilst this kinda makes sense -- we really only use MargPOptimizer -- this is not clean: the curves should be created as they are, and modified when reading into the Optimizer; however, this is a major change and it may not in practice be worth the effort.

[sklbancor]

@NIXBNT just making sure we agree that this is your PR; I just opened it for you