Noir contract: Implement a recursive function

[iAmMichaelConnor]

Here's an important test contract that I think we should build, as a way of testing the 'pending commitments' work done by @dbanks12 @jeanmon @suyash67...

• Make a copy of the zk_token_contract example.
• Remove the 'claim' stuff, because that's clutter for this example.
• At the moment, the transfer function can only get 2 notes. But what if I want to send 1000 tokens, but each of my notes only contains 10?
  • Well, we could implement a recursive transfer function.
• Transfer 1:
  • amount = 1000
  • sender = ME
  • recipient = Bob
  • Get 2 notes with values 10, 10.
  • If 10 + 10 < amount:
    • Don't create a note for Bob. Instead, create a note for Me, with value 20, and a change_note for Me with value 0. (Or, equivalently, you could use the existing code, but give Bob a note with value 0, but sending Bob an encrypted message with no value feels like a waste of on-chain calldata, and is effectively spamming Bob, so that would be less good).
    • Then call transfer again.
• Transfer 2:
  • amount = 1000
  • sender = ME
  • recipient = Bob
  • Get 2 notes with values 20, 10. Notice: the oracle needs to return the biggest note each time, so our sort and filter functions need to be designed accordingly, in the noir contract.
  • If 20 + 10 < amount:
    • Don't create a note for Bob. Instead, create a note for Me, with value 30, and a change_note for Me with value 0.
  • Then call transfer again.

etc.

• Transfer 100 (or maybe 99 or maybe 101 🤣 ):
  • amount = 1000
  • sender = ME
  • recipient = Bob
  • Get 2 notes with values 990, 10. Notice: the oracle needs to return the biggest note each time, so our sort and filter functions need to be designed accordingly, in the noir contract.
  • If 990 + 10 < amount:
    • // hooray! not the case anymore!
  • else:
    • Create a note for Bob with value 1000. Create a change note for me with whatever's left (0 with these example numbers).

The benefit of doing all this, is that a user only has to approve 1 transaction. The notion of notes is completely abstracted away from the user. It's LOVELY!

Notes:

• We might not be able to recurse 100 times, because squashing isn't being done at each iteration of the kernel yet? So the numbers might need to be smaller, based on the upper bounds of today's ordering circuit.
• Since our main aim is for 'proving in the browser', we aren't parallelising function execution yet. You could imagine, though, if we had a class of kernel circuits designed for a big beefy machine, we could design kernel circuits which recurse in a 'tree' structure. Then, we wouldn't need to build up the balances as X + 10 each time, we could instead combine the 10's in a 'tree' of function executions. Would be super cool, but it's a long way away.