test against epoch 3.0

[hugocaillard]

Because the stacks wire format changed with nakamoto, we want to make sure that chainhook can process epoch 3.0 block.

• chainhook relies on clarinet/components/stacks-codec to process block
  • this component is duplicated (and slightly altered) code from stacks-core
    • in the future we'd like to simply re-use the code from stacks-core, but unlikely top happen before nakamoto
    • it's slightly outdated right now, but is good enough for clarinet
    • it's not straightforward to update (and it's not tested at all)
• I think we should test chainhook with the current version of stacks-codec on a testnet running in epoch 3.0.
• if something goes wrong, we'll be able to upgrade the stacks-codec

I could go ahead and just try to update the stacks-codec right now, but considering how sensitive it is, I'd rather do it only to fix something (or make sure I don't actually break anything)

[hugocaillard]

Note:
The stacks-codec is very rarely updated (except for some recent clippy fixes that have no impact on the code execution).
Although if we want to be sure to know which version is being used, it's possible to specify the commit in the dependencies like so:

# chainhook/Cargo.toml

[patch.crates-io]
stacks-codec = { git = "https://github.com/hirosystems/clarinet.git", rev = "63dfdb2f5ed7013bb0ce29acf02b823e3eb1ffae" }

Or run cargo update stacks-codec to update to the latest version.

In both case, make sure that the cargo.lock is udpated with the right rev

[rafaelcr]

Tested on a local chainhook install running against stacks-regtest-env on every epoch transition and everything works correctly