feat: implement encryption to an address point and decryption from an address secret

[sklppy88]

Resolves #9326, #8966, #8969

This PR finally implements the new address scheme in encryption and decryption. We encrypt with the address's point, and decrypt with preaddress + ivsk (addressSecret).

Some nomenclature before we start:
The old address (h in Mike's presentation; hash(partialAddress, publicKeysHash)) -> preAddress
The secret corresponding to the address point -> addressSecret

The flow generally works by taking a secret, and deriving a valid point from it.

We then store the x-coordinate of this point as the address. We do this even though we know that this x-coordinate has two valid y-coordinates (a positive and negative one), but we do not store any information about the sign in the address.

Even still, we can support secrets that get computed into a positive and a negative y coordinate.

To do this, whenever we recompute the y-coordinate to recover the point from the x-coordinate, we make sure to encrypt to the positive point only. i.e. if we solve for y with x, and we get a negative coordinate, we subtract it from the Field modulus to get a positive one.

But if you think "hey, we can't do that, our secret corresponds to a negative y-coordinate", you would be right. In order to address this, we as the owner of the secret, can recompute our full point as we know all of the information that can derive this point. Thus we know what sign our "true" y-coordinate is. In this case, if our y-coordinate is negative, all we need to do is negate our secret (Field modulus minus secret) to derive the secret for point containing the negated negative (and now positive) y-coordinate.

You can see that this above process is being done, with the the encryption taking place in payload.nr, and that the decryption taking place in note_processor.ts.

Outstanding work:
The interface of getEvents in pxe_service should be investigated. With these changes it works... but it's unnecessarily disgusting I think.

The interface of the encryption api in payload.nr is extremely jank, but this pr is getting pretty big, so it will be handled imminently in #9390.

Look through the rest of the tests, think about replacing arbitrary addresses with "valid" ones.

Remove any excess code relating to needing the ivpk in both ts and nr

Docs and migration notes. As this change is pretty big I think it would be good to go through this also later / with someone on the devrel team to make sure the docs are comprehensively updated.

More of this stack doesn't show up on the graphite comment here:

[sklppy88]

• fix: replace npk_m_hash with addresses #9461 : 2 dependent PRs (#9463 , #9495 )
• fix: remove unnecessary ivpk's from aztec-nr #9460
• refactor: clean up note processor after changes due to address #9401
• fix: cleanup of janky encryption apis #9390
• feat: implement encryption to an address point and decryption from an address secret #9272 👈
• refactor: quick account manager refactor #9357
• chore: quick keystore refactor #9355
• chore: implement Fq add #9354
• feat: introduce default public keys and replace empty public keys #9277
• feat: modify private calldata to use public keys #9276
• master

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @sklppy88 and the rest of your teammates on Graphite

[sklppy88]

The changes in this file are a bit janky and should be fixed in a follow up PR, have noted it in the description.

[sklppy88]

This file's changes was just due to the formatter not being run on master

[Thunkar]

LGTM, awesome job!

[nventuro]

Lovely to see this finally be implemented! 🙌