refactor(katana-db): convert StorageChangeSet into a normal table

[kariy]

Resolves #1762

Convert StorageChangeSet into a normal table instead of dupsort.

This change is so to allow the block list of the StorageChangeSet to grow without being bounded by the value size of a DUPSORT table.

The max size for a DUPSORT table value is equal to the max size of the table key. So, when the list cardinality increases too much, the resulting subkey size will become larger than the max size. This will result in a MDBX_BAD_VALSIZE error.

[kariy]

• refactor(katana-db): convert StorageChangeSet into a normal table #1774 : 2 dependent PRs (#1775 , #1776 ) 👈
• style(katana-db): standardize naming for historical tables #1773
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @kariy and the rest of your teammates on Graphite

[codecov]

Codecov Report

Attention: Patch coverage is 85.07463% with 10 lines in your changes are missing coverage. Please review.

Project coverage is 67.19%. Comparing base (9c8b3b0) to head (bf93d45).
Report is 1 commits behind head on main.

❗ Current head bf93d45 differs from pull request most recent head c6f7c04. Consider uploading reports for the commit c6f7c04 to get more accurate results

Files	Patch %	Lines
...es/katana/storage/provider/src/providers/db/mod.rs	73.07%	7 Missing ⚠️
.../katana/storage/provider/src/providers/db/state.rs	85.71%	2 Missing ⚠️
crates/katana/storage/db/src/codecs/postcard.rs	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1774      +/-   ##
==========================================
- Coverage   67.42%   67.19%   -0.24%     
==========================================
  Files         305      305              
  Lines       33523    33607      +84     
==========================================
- Hits        22603    22582      -21     
- Misses      10920    11025     +105     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[glihm]

So normal tables should not be limited at all, right? Or is there any other boundary we need to be aware of in testing?

[kariy]

So normal tables should not be limited at all, right?

Basically yes. In this context, value size of a normal table will have a much higher upper bound than that of a dupsort table.

Or is there any other boundary we need to be aware of in testing?

These are the limitations set by mdbx for key/value size:

Key size: minimum 0, maximum ≈½ pagesize (2022 bytes for default 4K pagesize, 32742 bytes for 64K pagesize).
Value size: minimum 0, maximum 2146435072 (0x7FF00000) bytes for maps, ≈½ pagesize for multimaps (2022 bytes for default 4K pagesize, 32742 bytes for 64K pagesize).

but for DUPSORT, iiuc the data item in a DUPSORT is just another key in the underlying BTree map and thus must follow the key size constraint.

but because subkey of a dusport table is

[kariy]

Merge activity

• Apr 5, 9:34 PM EDT: @kariy started a stack merge that includes this pull request via Graphite.
• Apr 5, 9:35 PM EDT: Graphite rebased this pull request as part of a merge.
• Apr 5, 9:36 PM EDT: @kariy merged this pull request with Graphite.