Dynamic size optimization

[maximtim]

Rationale

Binary deposit tree currently has a fixed depth of 40 levels. This means that on any new deposit creation or
withdrawal there happens at least 40 storage writings, which update all tree nodes from the deposit leaf to
the root. The total number of possible deposits is 2^40, which was reserved for the least possible chance of
overflow, but seems to not be needed for a meaningful amount of time, so the most nodes of the tree remain
unused. Currently in the protocol there are ~10k deposits, which corresponds to ~0.0000009% of deposit tree
used. The possibility of optimizing the tree and reducing storage writings may be desirable.

Description

The suggested optimization is to have a minimal tree size from the beginning and to double it gradually,
when it's needed.
For example, with 5 deposits it's needed to have an 8-leaf tree, which has depth 3 (+1 root). It will spend only
4 storage writings on deposit and withdraw.
For N deposits it's needed to have a tree with [log2(N)] + 1 levels and 2^[log2(N)] leaves, where [x]
means ceil(x). For example, the tree with 10000 deposits will have a depth of 15 and
leaf number of 16384, which means 15 storage writing for deposit and withdraw, and it is ~3 times lower than
current gas spending.

The approach of implementation is having initial root value equal to LIQUIDITYNODES. It will
correspond to tree with 1 leaf - the root. All the other nodes are considered as "out of the tree".
The next step, when the number of deposits exceeds 1, is to double the tree, dividing the root root /= 2, so
it opens the tree with 2 leaves - [LIQUIDITYNODES, LIQUIDITYNODES + 1]. The new root is initialized with the old value root amount to ensure consistency. The higher numbers of leaves
are considered invalid aswell. The next doubling will be after 2 deposits, then 4, 8 and so on, increasing the tree gradually.

Existing operations for the tree are just diving from the leaf until
the root, and updating root happens when a number of new deposits is exceeded. No other change to the algorithm is done.

Result

The tested gas comsumption for most functions has significantly decreased (upper values are before, lower are after):

Contract	Method	Min	Max	Avg
LiquidityProtocol	add	33898	95441	49224
LiquidityProtocol	add	34189	96979	49690
······················	·······················	·············	·············	···········
LiquidityProtocol	addLimit	51544	578572	524546
LiquidityProtocol	addLimit	42194	191204	139178
······················	·······················	·············	·············	···········
LiquidityProtocol	nodeAddLiquidity	57097	980296	240254
LiquidityProtocol	nodeAddLiquidity	51544	266896	103320
······················	·······················	·············	·············	···········
LiquidityProtocol	nodeWithdraw	57144	472058	323085
LiquidityProtocol	nodeWithdraw	36644	135141	100571
······················	·······················	·············	·············	···········
LiquidityProtocol	nodeWithdrawPercent	64869	465129	442533
LiquidityProtocol	nodeWithdrawPercent	65598	137980	117448
······················	·······················	·············	·············	···········
LiquidityProtocol	remove	51578	505013	449635
LiquidityProtocol	remove	51974	144898	132139
······················	·······················	·············	·············	···········
LiquidityProtocol	removeLimit	54855	511878	95848
LiquidityProtocol	removeLimit	55612	129123	83794
······················	·······················	·············	·············	···········