Add tests to keep server_api json.go in sync with parse_inputs.rs

[ganeshvanahalli]

This PR adds CI steps to generate a InputJSON file corresponding to a block generated in a system test - TestProgramStorage and run arbitrator prover binary on this json file.

Recording of the block inputs' InputJSON file is now customizable via the flag options when running the test.

Flag | Default | Description
--recordBlockInputs.enable | true | "Whether to record block inputs as a json file"
--recordBlockInputs.WithSlug | "$TestName" | "Slug directory for validationInputsWriter"
--recordBlockInputs.WithBaseDir | "~/.arbitrum/validation-inputs/" | "Base directory for validationInputsWriter"
--recordBlockInputs.WithTimestampDirEnabled | true | "Whether to add timestamp directory while recording block inputs"
--recordBlockInputs.WithBlockIdInFileNameEnabled | true | "Whether to record block inputs using test specific block_id"

To test locally do this

$> go test github.com/offchainlabs/nitro/system_tests --run TestProgramStorage$ --count=1 --recordBlockInputs.WithBaseDir="some_valid_path" --recordBlockInputs.WithTimestampDirEnabled=false --recordBlockInputs.WithBlockIdInFileNameEnabled=false
ok  	github.com/offchainlabs/nitro/system_tests	3.268s

$> make build-prover-bin
<... snip lots of output ...>

$> target/bin/prover target/machines/latest/machine.wavm.br -b --json-inputs="some_valid_path/TestProgramStorage/block_input.json"
<... snip lots of output ...>

Resolves NIT-2820

[tsahee]

That's a very interesting approach. Took some good thinking..
However, I still prefer my original idea: make a system test that stores block to a path chosen by environment variable (or doesn't, if variable not set), have a ci step that runs this test to create a file, and then a ci step that launches prover with it and makes sure it passes.
The advantages of this approach is we see not only that format passed, but that we succeed in launching a machine from that info. For example, if we change "wavm" target name to something else.
Also, the test in the different approach could easily also test your other pr running a jit machine.
LMK if you disagree.

[ganeshvanahalli]

That's a very interesting approach. Took some good thinking.. However, I still prefer my original idea: make a system test that stores block to a path chosen by environment variable (or doesn't, if variable not set), have a ci step that runs this test to create a file, and then a ci step that launches prover with it and makes sure it passes. The advantages of this approach is we see not only that format passed, but that we succeed in launching a machine from that info. For example, if we change "wavm" target name to something else. Also, the test in the different approach could easily also test your other pr running a jit machine. LMK if you disagree.

Makes sense, I agree with your approach, as it guarantees we cover all cases and not just the parsing.

[tsahee]

seems good, but waiting for @eljobe to approve

addressed

[eljobe]

Thanks for sticking with this. Almost there.

[eljobe]

LGTM. One final nit-pick, but thanks for this.

[eljobe]

LGTM

[eljobe]

LGTM