Create a Controlled Testnet with the 0.2[Neon] Node and the existing Clarity VM

[saralab]

This Testnet will :

• help us test the Nakamoto Consensus rules as part of the 0.2[Neon Node].

• Use the current ClarityVM

• Run the API with support for the Nakamoto Tx Types: nakamoto coinbase, tenure change, tenure extension

• Will have an Explorer with Nakamoto support

• Have Stacks.js with the new tenurechange event support

• Will run against the Bitcoin Regtest:

• This is to allow seamless transition from integration tests -> Testnet

• ability to reset network easily

[wileyj]

this is the "private testnet" that we've done in the past

[CharlieC3]

@wileyj I'll be using the config.toml from this PR as a reference.

[wileyj]

closing in favor of #4171

[CharlieC3]

@wileyj #4171 has different requirements than this issue. Should this be reopened?

[wileyj]

reopening - i see the diff with #4171 now

[wileyj]

@saralab @obycode
question regarding this issue and #4171 - is the expectation that we'll want to run 2 separate testnets, one with each implementation of the clarity vm?
this seems a bit reductive - if the clarity wasm VM is ready, we should run the testnet with that vs splitting the work between 2 different versions.

my impression is that the first iteration(s) of the controled testnet will using the existing VM, then once clarity wasm is ready - we'll (reset and) update the testnet with the new VM and continue testing.

happy to discuss further if i'm missing the forest for the trees here, but the these two issues seem like they should be combined.

[saralab]

Closing the loop on this one , as we discussed on several conveesations this week:
We absolutely need 2 Testnets to benchmark the current VM against the Wasm. With the goal to identify any quick wins for the throughput gains on the current Clarity VM.