feat: Minimal globals in constant rollup data

[LHerskind]

Description

Replaces #861 to address #826. Extends ConstantRollupData with

• Move chainid from tx_request into tx_context
• Add version into tx_context
• Add global_variables (chain_id, version) to constants
• Force global_variables to match chainid and version to kernels in the base rollup.
• Add block_number and timestamp to global_variables
• Add the global_variables to public input hash in the root rollup, include it in L2 block

Checklist:

• I have reviewed my diff in github, line by line.
• Every change is related to the PR description.
• I have linked this pull request to the issue(s) that it resolves.
• There are no unexpected formatting changes, superfluous debug logs, or commented-out code.
• The branch has been merged or rebased against the head of its merge target.
• I'm happy for the PR to be merged at the reviewer's next convenience.

[rahul-kothari]

1. In solo_block_builder.buildL2Block(), we are now passing timestamp, but we are never setting it anywhere (for example in sequencer.buildBlock() which calls the buildL2Block()?
2. When we upgrade, it seems like there would be 2 places where we need to update chainID and version now? In sequencer-client.ts which instantiates the soloblock builder and the AztecRPCServer. Can we move these to configs instead? Maybe we don't want to have a default param for these values so that we are sure we are passing these correctly everywhere (will be helpful for upgrades).
3. The archiver processes L2 block logs and increments expectedNextL2BlockNum. Should there be a check to ensure this matches the l2 block it decoded? @spalladino

[rahul-kothari]

can we rename version to aztecVersion and chainId to baseChainID to make it more clear what these are. Otherwise, especially for noir devs this will be super super confusing

[LHerskind]

Technically they are both chainIds, so could also be baseChainId and rollupChainId 🤷. Version mainly chosen just to be different to chainId to make it clear it was not the same thing.

[rahul-kothari]

yea I am fine with baseChainId and rollupChainId!

[rahul-kothari]

is this from where the kernel circuit will add these values into its public inputs (I know we add it to base circuit's constants in the solo_block_builder.ts file)? If so, the chainID and version should be read from somewhere (like a config value), rather than us hard-coding no? Otherwise for every upgrade we might have to edit it here?

[LHerskind]

See the general comment; #882 (comment).

[LHerskind]

1. In solo_block_builder.buildL2Block(), we are now passing timestamp, but we are never setting it anywhere (for example in sequencer.buildBlock() which calls the buildL2Block()?

Timestamps will be constrained based on L1 contract in #830. As this is expected to break a lot of tests and such, I delayed that task to when we are actually enforcing it, which will be a separte PR.

2. When we upgrade, it seems like there would be 2 places where we need to update chainID and version now? In sequencer-client.ts which instantiates the soloblock builder and the AztecRPCServer. Can we move these to configs instead? Maybe we don't want to have a default param for these values so that we are sure we are passing these correctly everywhere (will be helpful for upgrades).

Similar to above, planned to address this when the values starting being constrained on L1 with #827 and #831