Backport dfuse support

[swatanabe]

No description provided.

[maoueh]

@swatanabe I would like to probably update the DEEP_MIND_VERSION line to print some kind of identifier for the "fork". The deep mind code internal structure to forward the transaction trace and accepted block and those changed based on the version to the logger.

On the reading part, based on the version information, I'm instantiating the correct decoder. Now, probably that the fork or some identifier will be required also so I would have access to more information on the decoding part to take a decision.

Now it's look like this:

• DEEP_MIND_VERSION 12 0 => EOSIO 2.0.x decoder
• DEEP_MIND_VERSION 13 0 => EOSIO 2.1.x decoder
• DEEP_MIND_VERSION 14 0 => EOSIO 2.2.x decoder

And proposition:

• DEEP_MIND_VERSION 12 0 => EOSIO 2.0.x decoder (inferred variant eosio)

• DEEP_MIND_VERSION 13 0 => EOSIO 2.1.x decoder (inferred variant eosio)

• DEEP_MIND_VERSION 14 0 => EOSIO 2.2.x decoder (inferred variant eosio)

• DEEP_MIND_VERSION mandel 13 0 => Mandel X.Y.Z decoder (probably based on 2.1.x) (variant mandel)

[swatanabe]

I suspect that the transaction trace and block are using the 2.0 format. The transaction and block format was changed in 2.1 to support pruning context free data and we have not and do not intend to backport this.

[maoueh]

The transaction and block format was changed in 2.1 to support pruning context free data and we have not and do not intend to backport this.

You still have return value right? I knew that pruning was not being ported over.

Hence why I decided to raise the "variant" in the DEEP_MIND_VERSION because now it's kind of an hybrid where it will have the return_value but not the pruning, hence I'll need dedicated structure for Mandel specifically.