refactor(experimental): provide account encoding on the data field

[buffalojoec]

This PR refactors the accounts schema to allow for providing specific account
data encoding only when requesting the data field, which is always going to
be a string of encoded data.

Accounts are queried from the RPC as jsonParsed by default, so when this field
is provided with an explicit encoding, it will return the account's data in
the requested encoding in the data field.

Note this means it's now possible to query multiple data encodings on accounts,
as depicted in the tests.

For more context, here's a review comment by @steveluscher on a previous PR:

#1837 (comment)

Important Note: This change will cause programAccounts queries to spam
the RPC for each account, as the resolver is called from each account's context.
This is remedied in the next commit in the stack.

[buffalojoec]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

Current dependencies on/for this PR:

• master
  • PR refactor(experimental): use json-stable-stringify with bigint support for cache keys #2022
    • PR refactor(experimental): fix memo instructions in GraphQL #2015
      • PR refactor(experimental): refactor GraphQL QueryArgs to LoaderArgs #2016
        • PR refactor(experimental): refactor GraphQL doc comments #2023
        • PR refactor(experimental): provide account encoding on the data field #2017 👈

This stack of pull requests is managed by Graphite.

[steveluscher]

I think what this code is doing is:

• unconditionally doing one account.load with no encoding
• doing account.loads with whatever encoding is on zero or more data fields in the subselection

What I hope we can make happen is stuff like this:

• If there are no data fields, fetch the account with the fastest-to-fetch encoding
• If there is one data field set to Y encoding, then both fetches in resolveAccount and in resolveAccountData should use Y encoding

Back to your queue for comments!

[steveluscher]

Maybe this is what you mean by ‘This is remedied in the next commit in the stack,’ but what should happen here is:

1. The account resolver introspects the query itself, and looks into its own subselection for direct child data fields.
   a. If there are no data fields, fetch the account with whatever encoding is lightest on the RPC.
   b. If there are data fields, fetch the account with one of those encodings (to ensure a cache hit between the fetch for the account and the fetch for at least one of the data fields).

[buffalojoec]

Yeah, I was going to tackle this in the next commit, but I guess now that I think of it there's no reason for this one then. 😅

[buffalojoec]

What I hope we can make happen is stuff like this:

• If there are no data fields, fetch the account with the fastest-to-fetch encoding
• If there is one data field set to Y encoding, then both fetches in resolveAccount and in resolveAccountData should use Y encoding

I think this is probably a good approach. I can latch into this to help with programAccounts, which would be complete spam city with this implementation. I might walk this one back.

[buffalojoec]

Closing to pull this off the current stack and introduce a new stack for schema revisions.

[github-actions]

Because there has been no activity on this PR for 14 days since it was merged, it has been automatically locked. Please open a new issue if it requires a follow up.