[Ignore for now] Try optimizing DA costs by not including Npk_m in a note

[benesjan]

Note: This issue is low priority and I created it just so that the idea is not forgotten.

We could remove the Npk_m from the note preimage and instead we could modify how a note hash is computed within a note and silo there the note hash with Npk_m. Then when spending the note we would:

1. Fetch the Npk_m from a registry (that will probably mean that we will fetch it from oracle and then do a public tree inclusion proof - the oracle would have account address as input and it would return all the historical nullifier public keys),
2. iterate through the nullifier pub keys and check whether hash(Npk_m, inner inner inner note hash) matches the note hash we have,
3. once we find the match we have the Npk_m without having it in the preimage.

Update: We might do the same thing for storage slot given that it's in ABI now. We might need to brute force a bunch of nullifier pub keys and slots but that should be totally ok given that the number of [nullifier pub key, storage slot] pairs is not expect to be large.

Requirements: We have to make sure we don't over-fit aztec.nr to always do a "hash note with nullifier public key" step, in case someone wants to do some other kind of note derivation. For this reason the extra siloing and later on bruteforcing of the Npk_m for nullification has to happen inside the NoteInterface::compute_note_content_hash and NoteInterface::compute_nullifier functions. I don't expect this to be a problem. In the compute_nullifier function we would just call an oracle which would try bruteforcing the note hash with all the owner's Npk_m keys and then return it.

[LHerskind]

We added npk_m_hash instead for the nullifiers to address this more neatly, should be in #5637.