feat: constraining note owner

[benesjan]

Fixes #1817

Checklist:

Remove the checklist to signal you've completed it. Enable auto-merge if the PR is ready to merge.

• If the pull request requires a cryptography review (e.g. cryptographic algorithm implementations) I have added the 'crypto' tag.
• I have reviewed my diff in github, line by line and removed unexpected formatting changes, testing logs, or commented-out code.
• Every change is related to the PR description.
• I have linked this pull request to relevant issues (if any exist).

[spalladino]

Looks good @benesjan, but I'd move the constrain to within the get_secret_key call. Not only to remove code duplication, but I think it's good practice if we can expose to the user functions that already constrain their result (like we're doing with get_public_key) so they don't have to it themselves and risk forgetting it.

That aside, I also wanted to ask: why flipping secret's high and low in this PR? I believe we usually go big-endian, which would mean serialising high first, right?

[benesjan]

Thank you for the review @spalladino .

I'd move the constrain to within the get_secret_key call.

Great idea. Will address.

why flipping secret's high and low in this PR? I believe we usually go big-endian, which would mean serialising high first, right?

I initially followed the big endian but then @kevaundray flipped it here so I flipped it in aztec-packages as well so that it's consistent. I guess in crypto they are used to having it like that.

[kevaundray]

Thank you for the review @spalladino .

I'd move the constrain to within the get_secret_key call.

Great idea. Will address.

why flipping secret's high and low in this PR? I believe we usually go big-endian, which would mean serialising high first, right?

I initially followed the big endian but then @kevaundray flipped it here so I flipped it in aztec-packages as well so that it's consistent. I guess in crypto they are used to having it like that.

I can open up an issue to make barretenberg use little endian everywhere, because I believe in some places it may use little endian and in others it will use big endian (There might be reason for this -- haven't checked)

[spalladino]

Heads up that all this logic is within an unconstrained function, meaning the assertions will not be enforced by the circuit (I'm wondering if this should be a compile error?). You probably want an unconstrained function that just wraps the oracle call, and then a non-unconstrained one that calls get_public_key, computes it from the secret, and runs the assertion (like in get_public_key.nr).