feat(recursion): memory access timestamp constraints

[kevjue]

No description provided.

[puma314]

@kevjue nice work! The biggest commits I pushed were just to directly record the byte events when creating the memory event (and in the runtime) since the recursion VM is much more simplified. With this, we can make sure that generate_dependencies for all of the chips is null which should speed up performance a little bit since we don't have to do trace generation to get all the byte events (which is what generate_dependencies defaults to).

I also added this method to stark::utils that allows us to debug_constraints on a runtime that has been run. This is nice because for test programs in the program folder that test parts of the verification program, we can debug constraints and interactions. For example, this is a good test to run:

cargo test --package sp1-recursion-program --lib --release -- fri::two_adic_pcs::tests::test_two_adic_fri_pcs_single_batch --exact --show-output 

I think right now the above fails, but I'm not sure that it is this PR's fault...something bad might have gotten merged into main.

[kevjue]

@kevjue nice work! The biggest commits I pushed were just to directly record the byte events when creating the memory event (and in the runtime) since the recursion VM is much more simplified. With this, we can make sure that generate_dependencies for all of the chips is null which should speed up performance a little bit since we don't have to do trace generation to get all the byte events (which is what generate_dependencies defaults to).

I also added this method to stark::utils that allows us to debug_constraints on a runtime that has been run. This is nice because for test programs in the program folder that test parts of the verification program, we can debug constraints and interactions. For example, this is a good test to run:

cargo test --package sp1-recursion-program --lib --release -- fri::two_adic_pcs::tests::test_two_adic_fri_pcs_single_batch --exact --show-output 

I think right now the above fails, but I'm not sure that it is this PR's fault...something bad might have gotten merged into main.

Thanks for the changes. I'll take a look at why its failing.

[puma314]

nit: "that the input"