implement logic to build genesis state for the sequencer

[rianhughes]

This PR implements the genesis pkg that builds a state diff from declaring classes, deploying contracts and invoking functions. The sequencer can then commit this state diff to state, so that upon startup, a set of account contracts have already been deployed and funded (it is not possible to achieve this from an empty state by submitting transactions, since Starknet requires accounts to be funded to perform any actions on the state - originally this wasn't a requirement in Starknet). This is particularly useful as it allows users to start the sequencer with any number of accounts pre-deployed, and pre-funded, etc, and opens up the possibility of using Juno as a devnet

In essence:

1. we load classes, then declare them,
2. execute the constructor functions using the vm, which writes the changes to the pending state
3. execute any functions of interest (eg token transfers) using the vm (where similarly the vm writes the changes to the pending state)
4. extract the state-diff and new classes from the pending state.

[codecov]

Codecov Report

Attention: Patch coverage is 66.38889% with 121 lines in your changes missing coverage. Please review.

Project coverage is 75.11%. Comparing base (1c29310) to head (c560082).

Files with missing lines	Patch %	Lines
genesis/genesis.go	63.39%	56 Missing and 26 partials ⚠️
sync/pending.go	60.37%	19 Missing and 2 partials ⚠️
adapters/vm2core/vm2core.go	71.05%	8 Missing and 3 partials ⚠️
core/state_update.go	85.36%	5 Missing and 1 partial ⚠️
node/throttled_vm.go	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2371      +/-   ##
==========================================
- Coverage   75.26%   75.11%   -0.16%     
==========================================
  Files         140      141       +1     
  Lines       16842    17198     +356     
==========================================
+ Hits        12676    12918     +242     
- Misses       3335     3419      +84     
- Partials      831      861      +30     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[AnkushinDaniil]

I have finished reviewing everything except vm logic. Everything is good, just small changes and questions. I'll continue reviewing vm logic.

[cicr99]

Even though the PR is approved, I'm adding the blocked label up until all the changes regarding the new blockifier release are finished. This takes priority and will probably cause conflicts with the changes done to the vm pkg in this PR.

[rianhughes]

Relevant blockifier PR #2397

[rodrigo-pino]

Just putting a blocking comment here to make sure it doesn't get merged by accident during this release process.

I would also like to give a final review before moving ahead with the PR.

[rodrigo-pino]

It's a very big PR so I left a lot of comments. Nonetheless, my general thoughts are that it is very good quality and the quantity of the comments is just due it's size.

[rodrigo-pino]

rename result to stateDiff. If you follow the upcoming suggestions we don't need this Var

[rodrigo-pino]

I know this pattern is what it's generally used but I prefer not to handle nil cases implicitly in the code. I think they should be handled explicitly. I believe they sum up for better readability for the long term (projects such as this) even if you have to write a bit more code.

For example, the caller of this function should check that it's input parameter is not nil and the function. The function instead will assume if it gets called, there will be always something to adapt.

Of course, I think this are among the most subjective things so feel free to ignore. The idea is that nil is an edge case that you should handle explicitly: "this function adapts from one to the other, it is not the role of this function to adapt nothing" (again, very subjective)

Finally, if you are staying with this approach, I think is better to just return core.StateDiff{}