feat(Keys_Viewing): Update encrypted log format

[LHerskind]

The format of encrypted logs should be altered to better match our requirements.

From the diagram we currently have a description as

However, this can be horribly inefficient for transactions that emit notes but don't wish to emit an outgoing note.

Instead, we can alter it such that we have a general incoming_encrypted_log as follows:

incoming_encrypted_log = {
  tag,
  ephemeral_public_key,
  ciphertext_header,
  ciphertext_note
}

And then have a separate outgoing_encrypted_log that have the rest.

outgoing_encrypted_log = {
  tag,
  ciphertext_header,
  ciphertext_note
}

Note, that there is not direct link between the two, but we know they are part of the same tx, so for decryption of the outgoing a user would match it against all the incoming_encrypted_logs in the transaction.

[LHerskind]

We should consider the exact format we will be using. Namely, when creating the final object, we have that using raw bytes that are only made into fields at the end will likely be using less data. A particularly annoying thing is that encrypting the address for the ciphertext_header when encrypted can be a full 32 bytes, and no longer fits into one field.

I think we should collect the bytes, as we can then use the other 30 bytes that we have available from this 1 byte extra to some other values, for example, we could likely have both the tag and the header sharing a bit.

[LHerskind]

As part of this work, we should be altering the compute_encrypted_log function in the private_context such that will be using the constrained ciphertext.

Currently the function is using the emit_encrypted_log oracle, to compute the encrypted message, which it is then blindly passing along for the log_hash.

I suggest we alter this to draw a eph_sh, query needed keys and then construct the header and the body as done in #5867 and #5899. Potentially alter these directly to slices. Then, we can change compute_encrypted_log_hash to take these encrypted bytes that we now have, and spit out the hash. For now, we can just set the tag to some placeholder that is ignored. Overall, we should sit with a slice of bytes that contains [tag, ephemeral_public_key, ciphertext_header, ciphertext_note]

The remainder of the function would be mainly the same, but we would change the emit_encrypted_log oracle to just be telling the node about the pre-image to the hash, such that the client_execution_context can still add it to its encryptedLogs and logsCache.

[LHerskind]

Speaking with Mike, and we will go back to the "one big log" for a note instead of splitting it into multiple sections. From #6348 there is a typescript implementation showing the encryption and decryption (both incoming and outgoing).

It should be "fairly" straightforward to implement the encrypt function in noir, alter the oracle that is currently emitting to just take raw bytes instead, and then alter the note_processor.

In particular, we should be able to modify the TaggedNote and EncryptedPayload such that the combined take the roled of the TaggedNote with the additional tag.

const taggedNote = TaggedNote.fromEncryptedBuffer(log.data, secretKey);

A interesting note that should make it slightly easier to implement. It is possible to set it up such that the plumbing can be handled before the noir implementation is even written 👀 But likely more convenient to match it first with just the payload similar to the other log tests (as #6334 and #6325)