[token-2022] Add support for reading proofs from record accounts

[samkim-crypto]

Problem

The token22 program does not yet have support for reading zk proofs from record program.

Summary of Changes

Added support for reading zk proofs from the record program.

7f510f4: Added support for the record program in the program. The main changes here are twofold:

• Updated the decode_proof_instruction_context function so that if the instruction data associated with the zk instruction is exactly 5 bytes, then read the proof from the supplied record account instead of reading it from instruction data. In the process, I changed the output type of the function to Result<U, ProgramError> instead of Result<&U, ProgramError> to simplify over-complication with lifetimes. All the functions that use decode_proof_instruction_context seem to immediately deref the context type anyway.
• Extended the ProofLocation type to have support for RecordAccount. Instead of having three variants of InstructionOffset, ContextStateAccount, and RecordAccount, I decided to overload InstructionOffset to support RecordAccount since this simplifies logic in some places.

b245e14: Added functions to create and close record accounts for confidential transfers. The main interesting part here is the calculate_record_max_chunk_size function, which provides the maximum chunk size for a proof record instruction to fit inside a single transaction. I included this function in token.rs, but I can move this to somewhere if suggested.

92caf61: For each of the instructions that require zkp's I added ...with_record_account() test variants to make sure that the record account works. Exceptions are the transfer (with/without fee) instruction. I omitted adding tests for these instructions because I will need to heavily modify/remove these instructions in a follow-up PR.

[joncinque]

I looked through a bit, and before I keep going, I wanted to check if we could somehow combine the proof source to be one of:

• the instructions sysvar
• context state account
• a record account

This might require updating proof_instruction_offset to be a bit clearer -- maybe we make it something like:

enum ProofLocation {
    ContextStateAccount
    InstructionOffset(i8),
    AccountData(u32),
}

Although it'll cause churn, I hope it'll be easier to understand -- what do you think?

[samkim-crypto]

I looked through a bit, and before I keep going, I wanted to check if we could somehow combine the proof source to be one of:

• the instructions sysvar
• context state account
• a record account

This might require updating proof_instruction_offset to be a bit clearer -- maybe we make it something like:

enum ProofLocation {
    ContextStateAccount
    InstructionOffset(i8),
    AccountData(u32),
}

Although it'll cause churn, I hope it'll be easier to understand -- what do you think?

Yeah the current version is the result of a number of attempts to simplify things, but it is still a bit confusing. The complication is that even if the proof is read from an account, you still need the sysvar to access the zk-proof instruction in the transaction. Unlike the case of context state accounts, if the proof is stored in a record account, it is not yet verified, so an accompanying zk instruction has to be checked for the correct proof type. Furthermore, the record account address also has to be included because you still need access the proof to use it in the token-2022 processor logic.

What I initially had was something like the following

enum ProofLocation {
    ContextStateAccount(Pubkey),
    InstructionData(InstructionOffset),
    AccountData(InstructionOffset, Pubkey), // need both the offset for the accompanying zk instruction and address for the record account
}

type InstructionOffset = i8;

Then I combined InstructionData and AccountData together to simplify the logic in instruction generation, but looking at it now, maybe the three-variant enum above is the clearest way to define things. What do you think?

[joncinque]

Ah gotcha, I knew I was missing something obvious, thanks for the explanation. In that case, it looks like you've done the best thing! I'll take a full look on Monday

[joncinque]

Just a couple of small things -- once I understood how it was working, it was pretty straightforward!

[joncinque]

Just one last little thing, then this can go in!

[joncinque]

Can you revert these changes?

[samkim-crypto]

Sorry I forgot to turn off the auto formatter...

Pull request has been modified.