EXPERIMENTAL: Remotion of KeysTable in `Domain`

[Giulio2002]

This is an experimental PRs which remove the use of keysTable from Domain, here is what was required as a consequence:

• We need to use the empty-val feauture of MDBX so I added a special val (etl.NilVal) which instead of translating to delete, translates to insert nil value. all delete operation use etl.NilVal.
• Unwind needed to be changed slightly to account for nil-vals
• collate was reworked to work with valsTable, which requires an extra sorting via keys with respected to stripped keys (without step suffiix)
• getLatestFromDB was reworked to use valsTable, it is just a Seek + Check if stripped key == input key. Commitment have variable length keys so Instead we move cursor to where the last element (step=0) would be and call Prev() until we get to the first. overall it is one less random lookup in exchange of a few extras sequential ones, so reading speed should have slightly improved.
• Prune was reworked and it keeps track of latest pruned step in a separate key in table TblPruningProgress

[awskii]

• getLatestFromDB was reworked to use valsTable, it is just a Seek + Check if stripped key == input key. Commitment have variable length keys so Instead we move cursor to where the last element (step=0) would be and call Prev() until we get to the first. overall it is one less random lookup in exchange of a few extras sequential ones, so reading speed should have slightly improved.

this could bring fullscan on each query since commitment reads from smallest prefix to largest during unfold. I want to use that fact by storing bt stateful cursors but first experiment was failed.

Prune already had GetExecV3PruneProgress and SaveExecV3PruneProgress and Domain itself responsible to keep track it's progress, not aggregator

Collate should use ETL instead of slice sorting due to potential sizes of collations.