refactor(AztecNr): Proper way to fetch portal addresses

[rahul-kothari]

perhaps context.l1PortalAddress for my own and an oracle call to determine someone else' portal address (given an L2 contract address).

Doesn't require any updates to noir compiler but just noir-aztec3 library and acir-simulator.

[iAmMichaelConnor]

We have context.this_portal_address() now.

I don't think it's possible to query the portal contract address of another contract, without making a call to that contract.

But I'll leave this issue open a little longer. If the portal address forms part of the L2 contract's address (I forget if this is true or not?), maybe an oracle call could grab the L2 contract address, and a function could assert the correctness, by hashing to compute the contract's address.

[Maddiaa0]

aztec-packages/yarn-project/aztec-nr/aztec/src/oracle/context.nr

Line 1 in a9678d1

#[oracle(getPortalContractAddress)]

For who ever picks up, there is a bare oracle call to get the address, but no check that it makes up the real address

related issue: #1464

[LHerskind]

Can use some of the logic from contract_inclusion.nr. However, as for other historical inclusion proofs, when the new header is available in context, this code can almost be used directly.

For this reason, temporarily blocked by #3937

[LHerskind]

I'm not sure how much we really need in here. So, the thing is, it might not be useful the value at all, or can be different from what it is doing. Is seems better that we are asking the app what it is doing. E.g., apps that want to expose that need to do so with functions and their own storage instead of a custom oracle here.

Would also mean that we don't need to constrain the oracle extra etc, we just delete it.

[LHerskind]

The oracles have been purged, and the portal_address removed so it is now to be queried similar to any other storage.