Refactor decoders to class hierarchy

[LukaszRozmej]

Changes

• Make use of base classes to share code for TxDecoders
• Based on Refactor TxDecoder #7334

Types of changes

What types of changes does your code introduce?

• Bugfix (a non-breaking change that fixes an issue)
• New feature (a non-breaking change that adds functionality)
• Breaking change (a change that causes existing functionality not to work as expected)
• Optimization
• Refactoring
• Documentation update
• Build-related changes
• Other: Description

[emlautarom1]

Personally I'm not a fan of using inheritance for code sharing but I can't argue with the fact that we can remove ~600 LOC with this change.

Some rigidity of a class based approach might make future refactors a bit trickier (ex. TxType will be removed`) but we can deal with it once it becomes a problem.

Overall LGTM and I would not have any issues merging it with the existing refactor PR but I would like to hear some additional opinions on this kind of design.

[emlautarom1]

We should also move the files to a TxDecoders folder (I forgot about that and left MyTxDecoder during development)

[LukaszRozmej]

Yes I actually did it, but reverted it as it made reviewing on github experience awful as it lost track they are edits. Will do it just before the merge.

[LukaszRozmej]

Personally I'm not a fan of using inheritance for code sharing but I can't argue with the fact that we can remove ~600 LOC with this change.

Some rigidity of a class based approach might make future refactors a bit trickier (ex. TxType will be removed`) but we can deal with it once it becomes a problem.

Overall LGTM and I would not have any issues merging it with the existing refactor PR but I would like to hear some additional opinions on this kind of design.

1. Yes it will evolve with further refactors.
2. Do we want class hierarchy? IMO it is not a problem, because, the base classes are fixed and should never change - worst-case scenario we will move some parts of the code to new virtual methods. New classes can then override fine-grained stuff or, if bigger changes are needed, override some base methods. Or if they need to be completely different, they can implement the interface.
3. If we really really don't want class hierarchy we can move some stuff to (static?) reusable methods and call them in the different classes.
4. I would leave TxType even after we go to class hierarchy for transactions.
5. In .net 9 we might be able to unify code for RlpStream and ValueDevcoderContext

[emlautarom1]

If there are no more comments on the approach then I'll merge this with the existing PR so we can wrap up the work on the decoders.