ATA: Extract associated-token-account-client crate from associated-token-account crate

[kevinheavey]

Problem

People often import spl-associated-token-account just to derive an associated token address. This makes the ecosystem dependency hell and bloat problem much worse.

Changes

• Make a new spl-associated-token-address that contains just the get_associated_token_address* functions.
• Re-export these functions in spl-associated-token-account with a deprecation notice

This branches off #6989 so that should be merged first

[buffalojoec]

@kevinheavey looks like this one is also going to be closed, as per the solution proposed in #6989? Fwiw, we are close to said clients.

[kevinheavey]

This basically is the solution proposed in #6989 no?

[buffalojoec]

This basically is the solution proposed in #6989 no?

Oops, I don't think I was following the bouncing ball over there.

This is looking pretty good, but I believe @joncinque had some additional thoughts so I'll let him weigh in on this one.

[joncinque]

@kevinheavey I worked this a bit to be a complete client crate that exposes the instruction creators along with the address derivation functions. This way, we remove a dependency from token-client to the ata program, which means that I don't have to bump and publish the ata program every time there's a new version of token-2022, which always felt wrong.

Let me know what you think!

[kevinheavey]

@joncinque lgtm, full send

[buffalojoec]

Looking great! Are you planning to replace this with a generated client in the future (say, version 2.0.0)? A lot of the interface can be reusable, but it will also break. An alternative would be to try t to hand-write an IDL now and generate now.

Pull request has been modified.

[joncinque]

Are you planning to replace this with a generated client in the future (say, version 2.0.0)?

I want to avoid using the generated clients for now because it'll bring in a lot of extra dependencies that aren't needed. But yeah, we'll eventually add those in. And then it's up to us if we decide to break the existing instruction creators.

Everything else should be addressed!