Support Account Data for Seeds in Account Resolution

[buffalojoec]

This PR adds support for account data as a seed configuration for a PDA stored
within validation data.

A dynamic program-derived address may depend on one or more seeds that are
actually taken from the inner data of some account in the list of accounts
provided to the program.

Design Notes

There are a few notes to consider with this design.

The notes below each section will be tied to specific commits.

Separation of Off-Chain and On-Chain

Similar to the layout of the helpers in the Transfer Hook Interface, the
functions within TLV Account Resolution are now separated into off-chain and
on-chain use case categories.

Even though they share much of the same functionality, the main reason this
was done is because of the fact that on-chain programs can't use
async/await. Therefore, they couldn't share the same Fut closure.

Can we share some more of the code between the two APIs?

Repeated get_program_data_fn Invocations

Currently there is no mechanism in place to mitigate the amount of repeated
invocations of the F(Pubkey) -> Fut closure.

For example, if two or more PDA seed configurations within a program
instruction's validation data depend on the account data of some account in the
list, we want to avoid invoking the closure more than once for the same account.

Right now, each time a Seed::AccountData config is encountered, the closure
is invoked.

Can we avoid repeating these calls for the same account?

It's worth mentioning we could just put the onus on the user to add some client-level caching to their get_account_data_fn closure.

[joncinque]

All of those copied functions are definitely annoying... as a first pass, how about having the offchain version fetch all of the accounts in the instruction before using the same helpers? It means some more network calls, but it's not a huge deal. What do you think?

[buffalojoec]

All of those copied functions are definitely annoying... as a first pass, how about having the offchain version fetch all of the accounts in the instruction before using the same helpers? It means some more network calls, but it's not a huge deal. What do you think?

I plucked my comment because that's what I just laid down ha! But yeah, the network calls are a bit overkill. However, it solves both the copy-pasta and cloning issues. 1 evil < 2 evils?

[buffalojoec]

1021f2c is my first-pass attempt at condensing the duplicated API functions, ie. addressing design note 1.

as a first pass, how about having the offchain version fetch all of the accounts in the instruction before using the same helpers?

Is this what you had in mind?

[joncinque]

Yeah that's definitely on the right track.

I haven't thought this through totally, but rather than separating out the addressable part and the data part, how about doing everything through AccountInfo? You can fetch the accounts off-chain create AccountInfos out of them thanks to https://github.com/solana-labs/solana/blob/7bd74105923f3f02058a9ae8854ca2ae704e92e1/sdk/src/account.rs#L721, and use the same exact stuff as on-chain, and those are exactly the type you want: data, address, writability, etc

This might end up being even cleaner than before! Kinda

[buffalojoec]

I haven't thought this through totally, but rather than separating out the addressable part and the data part, how about doing everything through AccountInfo? You can fetch the accounts off-chain create AccountInfos out of them thanks to https://github.com/solana-labs/solana/blob/7bd74105923f3f02058a9ae8854ca2ae704e92e1/sdk/src/account.rs#L721, and use the same exact stuff as on-chain, and those are exactly the type you want: data, address, writability, etc

Cool, thanks! I'll take a look. I went with the Addressable approach in that commit only because I'm holding out hope I can eliminate the need to call get_account_data_fn on every account in the list. We shall see!

[buffalojoec]

Closing for #5182