sdk: introduce trait based StorageAPI (wip)

[joshieDo]

closes #11243

tldr: each chain needs to write/read their own blocks. Eg. Not all chains may want Ommers as part of a block. These components are spread across different tables and need to be assembled.

Creating the PR to initiate a discussion. I think the first question is how to pass this from ProviderFactory<N> to DatabaseProvider. Right now it takes <TX, Spec> as generics. #11872 Adds a new StateCommittment generic. If we add a storage one, it's too much. Thoughts?

some options:

• unify Spec and Storage under yet another Node trait ? What about SC?
• pass N/NodeTypes from ProviderFactory (proposed here with DatabaseProvider2)
• just add Storage generic
• methods that require assembling a block take ChainStorageReader

[jenpaff]

closes #11243

tldr: each chain needs to write/read their own blocks. Eg. Not all chains may want Ommers as part of a block. These components are spread across different tables and need to be assembled.

Creating the PR to initiate a discussion. I think the first question is how to pass this from ProviderFactory<N> to DatabaseProvider. Right now it takes <TX, Spec> as generics. #11872 Adds a new StateCommittment generic. If we add a storage one, it's too much. Thoughts?

some options:

• unify Spec and Storage under yet another Node trait ? What about SC?
• pass N/NodeTypes from ProviderFactory (proposed here with DatabaseProvider2)
• just add Storage generic
• methods that require assembling a block take ChainStorageReader

how confident are you with our existing tests to make sure we're not breaking anything with this? I know there's been quite a bit of work around it

[joshieDo]

although the trait would be introduced in this PR, it wouldnt actually be used afaik. Primitive traits still need more work. So it should not break anything

[mattsse]

yeah this progress will flag all the things that we need to do first to get unblocked