feat(nano): support key mangling for nested container fields

[jansegre]

Motivation

Before this PR, compound containers fields will fully serialize the whole contents of contained fields:

class MyBlueprint(Blueprint):
    records_per_address: dict[Address, list[bytes]]

Would mean each list[bytes] is fully serialized, which hinders large lists.

This PR makes it so the list[bytes] above is serialized as a records: list[bytes] field would be (using a DequeContainer), but using a dynamic prefix, instead of a prefix that only uses the field name, so (field_name, key) would become the prefix used by DequeContainer.

Impact

Currently we support 3 types of containers (before this PR, they were only "attached" directly to fields), they are: DequeContainer, DictContainer, SetContainer. Out of this 3, only a DequeContainer is iterable.

By making inner containers also use our container implementations, some of them will not behave like the native Python type that it is replacing. For example:

class MyBlueprint(Blueprint):
    distances: dict[str, dict[str, int]]

In the blueprint above, distances['foo'] would return a dict[str, int] which is Iterable, however after this PR it will return something equivalent to a DictContainer, whic is not Iterable. That is, previously distances['foo'].keys() would work, but after this PR it will no longer be the case.

The same happens for a set[T], but in this case the old behavior can be achieved using frozenset[T] instead. A dict however, doesn't really have a "frozen" equivalent, a mappingproxy comes close, but we don't allow it to be imported, in theory we could support something like mappingproxy[K, V].

Another impact is that foo: tuple[dict[K, V]] will make it so foo[0] still has the old behavior. But it's planned that a TupleContainer is introduced to make foo[0] return a DictContainer.

Acceptance Criteria

• Make Field not generic anymore, now it is the only concrete field type that carries a ContainerNodeFactory
• Introduce a "container system":
  • a ContainerNode is an abstract type that can be either a ContainerProxy or a ContainerLeaf, a ContainerNode is never directly accessible in Blueprint code
  • a ContainerProxy implements operations that compound the db-prefix until the operations reach a ContainerLeaf
  • a ContainerLeaf implements operations on a specific NCType that actually stores data in the contract storage
  • a Container abstract some common functionality that all containers have, whether a container uses a ContainerNode depends on the specific implementation, a concrete implementation of a Container is what ends up being used in runtime when a blueprint does self.foo[1] for example, so starting from a Container it is important to not expose anything to blueprint code, this is achieved by only using double underscore properties (either __dunder for private, implementation-specific properties; or __special__ for properties that have to be accessible to some other class/module but not the blueprint)
  • a SetContainer uses ContainerLeaf directly, not a ContainerNode, because it doesn't allow its members to mutate
  • a DequeContainer uses a ContainerNode to represent its members, it doesn't know directly whether a member is a ContainerProxy or a ContainerNode, but it operates on them through the abstract operations of a ContainerNode
  • a DictContainer uses a bare NCType to serialize keys (since they are only needed for generating the prefix for the values) and a ContainerNode to work with its values, similarly to how a DequeContainer does it
  • tests are adapted to these changes, but more tests covering new container combinations will be created in a continuation PR
  • a container can be deleted as long as it is empty, otherwise it will fail
  • a container can only be set once, for it to be set again the previous container must be deleted

Checklist

• If you are requesting a merge into master, confirm this code is production-ready and can be included in future releases as soon as it gets merged

[github-actions]

Bencher Report

Branch	feat/nested-container-fields
Testbed	ubuntu-22.04

🚨 1 Alert

Benchmark	Measure Units	View	Benchmark Result (Result Δ%)	Upper Boundary (Limit %)
sync-v2 (up to 20000 blocks)	Latency minutes (m)	📈 plot 🚷 threshold 🚨 alert (🔔)	2.02 m (+20.46%) Baseline: 1.68 m	2.01 m (100.38%)

Click to view all benchmark results

Benchmark	Latency	Benchmark Result minutes (m) (Result Δ%)	Lower Boundary minutes (m) (Limit %)	Upper Boundary minutes (m) (Limit %)
sync-v2 (up to 20000 blocks)	📈 view plot 🚷 view threshold 🚨 view alert (🔔)	2.02 m (+20.46%) Baseline: 1.68 m	1.51 m (74.71%)	2.01 m (100.38%)

🐰 View full continuous benchmarking report in Bencher

[codecov]

Codecov Report

❌ Patch coverage is 87.21805% with 51 lines in your changes missing coverage. Please review.
✅ Project coverage is 85.83%. Comparing base (8f23d02) to head (95b75f6).
⚠️ Report is 2 commits behind head on master.

Files with missing lines	Patch %	Lines
hathor/nanocontracts/fields/dict_container.py	68.11%	19 Missing and 3 partials ⚠️
hathor/nanocontracts/fields/container.py	92.59%	6 Missing and 6 partials ⚠️
hathor/nanocontracts/fields/deque_container.py	80.70%	6 Missing and 5 partials ⚠️
hathor/nanocontracts/fields/set_container.py	92.10%	2 Missing and 1 partial ⚠️
hathor/nanocontracts/fields/field.py	91.30%	2 Missing ⚠️
hathor/nanocontracts/nc_types/tuple_nc_type.py	0.00%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1312      +/-   ##
==========================================
- Coverage   86.03%   85.83%   -0.21%     
==========================================
  Files         432      430       -2     
  Lines       32822    32973     +151     
  Branches     5114     5161      +47     
==========================================
+ Hits        28239    28301      +62     
- Misses       3575     3639      +64     
- Partials     1008     1033      +25     

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[msbrogli]

I couldn't find tests that confirm that final key used to store compound types in the RocksDB storage.

[jansegre]

I'll add some tests for this.

[jansegre]

Test will be added in the next PR.

[glevco]

Shouldn't we assert pytest.raises(KeyError) for this case?

[jansegre]

This doesn't happen because of the implicit creation.

[glevco]

We should remember to readd this when the implicit creation is removed, then