Migration of block state values

[allanbrondum]

Purpose

Protocol migration of the Rust block state.

Changes

• trait block_state::migration::Migrate that defines and describes how to migrate a block state value
• implementation of the trait on all the block state types

We may need to add protocol version or migration target type (type Migrate::ToType) at some point, but keeping it as simple as possible for now.

Checklist

• My code follows the style of this project.
• The code compiles without warnings.
• I have performed a self-review of the changes.
• I have documented my code, in particular the intent of the
  hard-to-understand areas.
• (If necessary) I have updated the CHANGELOG.

[codecov]

Codecov Report

❌ Patch coverage is 95.04132% with 12 lines in your changes missing coverage. Please review.
✅ Project coverage is 63.99%. Comparing base (83b02b6) to head (440ee7a).

Files with missing lines	Patch %	Lines
plt/plt-block-state/src/ffi/block_state.rs	0.00%	7 Missing ⚠️
...block-state/src/block_state/smart_contract_trie.rs	89.79%	5 Missing ⚠️

Additional details and impacted files

@@                            Coverage Diff                             @@
##           feature/rust_block_state_p11_migration    #1628      +/-   ##
==========================================================================
+ Coverage                                   63.90%   63.99%   +0.09%     
==========================================================================
  Files                                         356      357       +1     
  Lines                                       71251    71470     +219     
  Branches                                     3032     3035       +3     
==========================================================================
+ Hits                                        45534    45739     +205     
- Misses                                      22685    22696      +11     
- Partials                                     3032     3035       +3     

Files with missing lines	Coverage Δ
plt/plt-block-state/src/block_state.rs	93.16% <100.00%> (+2.75%)	⬆️
...state/blob_reference/hashed_cacheable_reference.rs	98.29% <100.00%> (+0.27%)	⬆️
plt/plt-block-state/src/block_state/blob_store.rs	76.00% <ø> (ø)
plt/plt-block-state/src/block_state/lfmb_tree.rs	93.16% <100.00%> (+0.91%)	⬆️
plt/plt-block-state/src/block_state/migration.rs	100.00% <100.00%> (ø)
...ate/src/block_state/state/protocol_level_tokens.rs	88.42% <100.00%> (+1.86%)	⬆️
...block-state/src/block_state/smart_contract_trie.rs	94.37% <89.79%> (-0.83%)	⬇️
plt/plt-block-state/src/ffi/block_state.rs	0.00% <0.00%> (ø)

... and 6 files with indirect coverage changes

[td202]

I am not sure that it's a good idea to have a universal Migrate trait like this. At the moment, for the Rust code it's mostly just copying things for P10->P11 migration, so it works. But in general, migrations can alter data, possibly using context provided as part of the protocol update, or even doing more complex things, including changing types. I would rather that types have their own migration functions that are not abstracted by a trait, and can, for instance, be specific to the version migration taking place. For instance migrate_trivial for where the data and representation is unchanged, or migrate_p10_to_p11 that involves changes that are specific to that protocol update.

[allanbrondum]

Right now I think having the trait is easier, because it is used as trait bound in migration code for HashedCacheableRef and LfmbTree (which would otherwise take a closure). We can remove the trait again if it because a problem (or modify the trait). Until we have the block state model in place, I would rather leave the path open and see what works.