[Stacks v1 → v2 Upgrade] Import STX balances & vesting into Stacks 2.0

[zone117x]

Closes #2086

Uses a rust build script to compress the STX balance and vesting contents from chainstate.txt into deflate streams. These are embedded in the binary using include_bytes!(...). The binary is ~8MB larger. The compression and embedding is contained in a separate lib to make local dev less painful (rebuilds are not slowed down when making changes to the main src).

This file contains the all STX balances and vesting entries from Stacks 1.0.
(Note: it also contains on-chain name metadata, but name related data is not handled in this PR).

Combined, there are nearly 400k entries from a Stacks 1.0 export. An iterator<T> is used to alleviate boot memory usage issues. This PR includes a sample chainstate.txt file with only 10s of entries, which loads instantaneously. When the final Stacks 1.0 migration PR is opened, it will commit the full ~20MB chainstate.txt file.

The initial token balances are emitted as STX mint events in the pseudo-genesis-block. Emitting the token vesting entry calls is still WIP -- may need to be done after PR #2109.

[zone117x]

@kantai do you have any idea about this pox related test failure? Locally, cargo test --workspace --bin=stacks-node -- --test-threads 1 --ignored passes every time for me, but fails every time in CI. I'm not sure how the changes could cause this.

[kantai]

The bitcoind tests additionally require setting BITCOIND_TEST=1 to test. It looks like the failure may be due to the burn height calculation changing during genesis initialization -- the "unlock" height for the stack-stx operation appears to have changed.

[kantai]

This LGTM! Though I think this may need to be opened against next, rather than master, because this would change the change consensus (the genesis block is different, so this would cause a chain split).

[jcnelson]

LGTM!

[jcnelson]

I think we need to discuss whether or not all of the STX are minted in the genesis block and dolled out by the lockup contract (i.e. what's written now), versus having STX minted on-the-fly when the unlock height comes. I think it will have a painful impact on PoX if we do the former.

[jcnelson]

Almost there -- please change the .unwrap() to .expect() and make sure there's an open an issue describing how eagerly minting all the locked-up STX at boot-time effectively breaks PoX. Once these two tasks are done, then it LGTM.

[blockstack-devops]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.