bug: simulator oracle getNotes' leaf index does not match private data tree

[dbanks12]

This bug was discovered with the introduction of read requests. Prior to this there were 0 membership checks occurring for reads of private notes/commitments.

In client_execution_context.ts's fetchNotes, the calll simulator oracle's getNotes retrieves a leaf index from the DB that does not match its location in the private data tree. Debugging the e2e cross chain messaging test led to the discovery that when leafIndex 5 is communicated from the simulator (via getNotes2), the corresponding leaf is 0, but the commitment described by its read request lives at leaf index 17.

• call to simulator oracle getNotes in client_execution_context
• leaf indices are added to an array to be communicated to kernel prover here in private_execution's getNotes2
• kernel prover passes read request indices to private kernel here

I debugged this by adding in helper functions on the kernel oracle and aztec node to get leaf index by value etc. This exposed that when the the simulator oracle says there is a valid note at index 5, the node says there is no commitment at that index, and in fact that commitment exists at leaf index 17.