fix: Don't reuse brillig with slice arguments

[sirasistant]

This is a quick fix after #5737 since that PR assumes that one generated brillig is valid for all calls to the brillig function. This is however not true, since the generated brillig can differ if the arguments contains slices. This is because the entry point codegen depends on the size of the slice.
We currently cannot copy slices of any length into brillig due to the limitations of CALLDATACOPY where the size being copied needs to be known at compile-time. I'm going to chat with the AVM team to see if we can lift this restriction and make brillig entry points be able to copy in arguments that contain slices of any length.

[AztecBot]

Benchmark results

Metrics with a significant change:

• note_trial_decrypting_time_in_ms (8): 101 (+150%)

Detailed results

All benchmarks are run on txs on the Benchmarking contract on the repository. Each tx consists of a batch call to create_note and increment_balance, which guarantees that each tx has a private call, a nested private call, a public call, and a nested public call, as well as an emitted private note, an unencrypted log, and public storage read and write.

This benchmark source data is available in JSON format on S3 here.

L2 block published to L1

Each column represents the number of txs on an L2 block published to L1.

Metric	8 txs	32 txs	64 txs
l1_rollup_calldata_size_in_bytes	772	772	772
l1_rollup_calldata_gas	6,844	6,844	6,820
l1_rollup_execution_gas	587,325	587,325	587,301
l2_block_processing_time_in_ms	1,433 (-1%)	5,286 (-2%)	10,419 (+1%)
note_successful_decrypting_time_in_ms	197 (-18%)	575 (+15%)	965 (-7%)
note_trial_decrypting_time_in_ms	⚠️ 101 (+150%)	83.4 (-22%)	82.5 (+34%)
l2_block_building_time_in_ms	13,356	52,655	105,221 (+1%)
l2_block_rollup_simulation_time_in_ms	13,125	51,809	103,562 (+1%)
l2_block_public_tx_process_time_in_ms	5,745	22,476	45,312 (+1%)

L2 chain processing

Each column represents the number of blocks on the L2 chain where each block has 16 txs.

Metric	5 blocks	10 blocks
node_history_sync_time_in_ms	15,794	30,749 (+6%)
note_history_successful_decrypting_time_in_ms	1,117 (-10%)	2,303 (-1%)
note_history_trial_decrypting_time_in_ms	42.4 (-28%)	92.3 (-1%)
node_database_size_in_bytes	18,726,992	35,057,744
pxe_database_size_in_bytes	29,859	59,414

Circuits stats

Stats on running time and I/O sizes collected for every circuit run across all benchmarks.

Circuit	circuit_simulation_time_in_ms	circuit_input_size_in_bytes	circuit_output_size_in_bytes
private-kernel-init	152 (+1%)	44,725	26,424
private-kernel-inner	162	72,200	26,424
private-kernel-ordering	111 (-1%)	51,090	39,297
base-parity	41.3 (+1%)	128	311
root-parity	7.29 (+1%)	1,244	311
base-rollup	16,253 (+1%)	110,820	957
root-rollup	47.2 (+1%)	4,551	821
public-kernel-app-logic	89.0	48,175	40,933
public-kernel-tail	123 (-1%)	60,044	7,385
merge-rollup	7.46 (-6%)	2,760	957
public-kernel-teardown	85.5	48,175	40,933
public-kernel-setup	84.5	48,175	40,933

Tree insertion stats

The duration to insert a fixed batch of leaves into each tree type.

Metric	1 leaves	16 leaves	64 leaves	128 leaves	512 leaves	1024 leaves	2048 leaves	4096 leaves	32 leaves
batch_insert_into_append_only_tree_16_depth_ms	11.0 (-1%)	17.6	N/A	N/A	N/A	N/A	N/A	N/A	N/A
batch_insert_into_append_only_tree_16_depth_hash_count	16.8	31.6	N/A	N/A	N/A	N/A	N/A	N/A	N/A
batch_insert_into_append_only_tree_16_depth_hash_ms	0.639 (-1%)	0.546	N/A	N/A	N/A	N/A	N/A	N/A	N/A
batch_insert_into_append_only_tree_32_depth_ms	N/A	N/A	51.3 (+1%)	80.3	261	502	985 (+1%)	1,955	N/A
batch_insert_into_append_only_tree_32_depth_hash_count	N/A	N/A	96.0	159	543	1,055	2,079	4,127	N/A
batch_insert_into_append_only_tree_32_depth_hash_ms	N/A	N/A	0.527 (+1%)	0.496	0.476	0.469	0.468 (+1%)	0.468	N/A
batch_insert_into_indexed_tree_20_depth_ms	N/A	N/A	60.4 (+1%)	120 (+1%)	377 (+1%)	738 (+1%)	1,471 (+1%)	2,954 (+1%)	N/A
batch_insert_into_indexed_tree_20_depth_hash_count	N/A	N/A	105	207	691	1,363	2,707	5,395	N/A
batch_insert_into_indexed_tree_20_depth_hash_ms	N/A	N/A	0.535 (+1%)	0.539	0.513	0.508	0.510	0.515 (+1%)	N/A
batch_insert_into_indexed_tree_40_depth_ms	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	67.6 (+1%)
batch_insert_into_indexed_tree_40_depth_hash_count	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	109
batch_insert_into_indexed_tree_40_depth_hash_ms	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	0.591

Miscellaneous

Transaction sizes based on how many contract classes are registered in the tx.

Metric	0 registered classes	1 registered classes
tx_size_in_bytes	41,029	528,895

Transaction size based on fee payment method

Metric	native fee payment method	fpc_public fee payment method	fpc_private fee payment method
tx_with_fee_size_in_bytes	905	1,161	1,377

Transaction processing duration by data writes.

Metric	0 new note hashes	1 new note hashes	2 new note hashes
tx_pxe_processing_time_ms	1,198 (+2%)	798 (-1%)	3,473 (+1%)

Metric	1 public data writes	2 public data writes	3 public data writes	4 public data writes	5 public data writes	8 public data writes
tx_sequencer_processing_time_ms	501 (+1%)	331	899	418	1,496 (+1%)	490 (+1%)

[TomAFrench]

LGTM

[vezenovm]

Feels a little cumbersome to match on all the parameters when we are only worried about slices. Granted I realize this was a quick fix and thanks for resolving the issue.