Refactor CompleteAddress and AztecAddress and the related functionality

[benesjan]

When integrating the new keystore a lot of the address computation functions became outdated and weird to use. It should all be refactored and CompleteAddress should be "re-thought" because it's content is no longer sufficient to derive contract address. Should it contain publicKeysHash instead of public key? Or should it contain preimage of the public keys hash?

[LHerskind]

@iAmMichaelConnor lets discuss this one in the coming days.

[iAmMichaelConnor]

Sure! I'll need a reminder at the start about what the code is doing at the moment :)
I didn't pay much attention to the "complete address" stuff, because I already had in mind that we'd be changing it in favour of the latest keys spec.

[benesjan]

@iAmMichaelConnor Here is a summary. Currently the CompleteAddress contains the contract partial address, contract address and encryption public key (note that the new key stuff has not yet been reflected here at all). We created this type as it was all that you needed to send someone a note - you had the encryption public key and the account contract address and you could hash partial address with the public key to derive the account address and that way validate that the info you have is legit.

Now we need to re-think what to do with this type as the "flow of keys" when creating a note for someone is completely different with the new scheme. I suppose we need to support these 2 cases:

1. User has keys registered in the registry - in that case it does not make sense to use CompleteAddress and instead you would just pass around aztec address and fetch the necessary keys from it when necessary,
2. user keys are not registered in the registry. In this case we would use this CompleteAddress and refactor it such that it contains preimage of public keys hash, partial address and contract address - with this info you could validate the contents.

Now comes the question of how to handle this implementation-wise. We currently have the registerRecipient endpoint on PXE which has the complete address as arg. We can keep that around and make it a requirement (when sending a note) that a recipient is registered there if he has not been registered in the registry. Then all the oracles would always first try to fetch the keys from registry, if they were not there we would try to fetch it from the PXE recipients db (and then validate the complete address in Noir) and if it was not in db we would throw an error.

@iAmMichaelConnor after all, I feel like this is quite uncontroversial and probably does not need your input.

Doing this refactor will result in a ton of changes in the codebase.