Sell Token Account Deallocation on Settlement

[kaze-cow]

Description

Closes a sell token account after pulling funds if its empty and the settlement's state account has close_authority

Motivation

There are various places where a feature like this comes in handy:

• As a piece in a replacement for solflow--since we want to ensure the creation of a WSOL account does not need to be included in the order cost calculations, or remain open after the user's order is processed, we can auto reclaim it for the user once the order is processed.
• In general if a user is completely cashing out of a token (ex. a throwaway/airdrop), this makes for a really easy way to ensure there is nothing dangling
• Buffer reclamation--aside from the ReclaimBuffers command which we will already have to close token accounts (reclaim buffer account #60), if we have an instruction that allows for the fee reclaimer to place orders on behalf of the settlement account, the settlement could also close its own buffer account while cashing out all tokens using this method. This should naturally work because the settlement account owns its own buffer accounts!

Moreover, its easy and safe for a user to provide the permission needed to make this happen! SPL tokens provide a separate role explicitly for CloseAuthority, which only allows for the supplied account to close the account once it contains 0 balance. So if the user grants close authority to the settlement program, that can be treated as a certain "opt in". The close authority can be granted as part of the same multicall that places the order.

Considerations

Who receives the rent?

How we determine this can have a signfiicant impact on what flows we support in the above motivations and how many accounts an order uses.

1. (cheapest) Send funds to buy_token_account. In the case that the buy_token_account is already funded, it would just become surplus rent. In the case that buy_token_account is WETH, we could hypothetically call SyncNative to include the amount in the swap output. This technically keeps funds in the user's control, but locked in the destination account until a future time. This method has the benefit of not consuming an additional token account (since the buy_token_account is duplicated) and you could hypothetically fund the rent for the new token account using the old one (if its NOT token 2022). Ofc this has problems if you are sending to a different receiver, or if you are looking at .
2. (most natural) Sends funds to the order owner's wallet.
3. (most flexible) Send tokens to an account specified in the signed OrderIntent. This requires growing the size of the OrderAccount substantially from 200->232 bytes, and the solver would need to specify the target rent recipient as part of the BeginSettle, so this turns out to be substantially more complicated than the other two options above.

After some discussion, we elect to do option 3. This is perhaps the most complicated outcome, but its also the one we are probably going to settle on with this feature.

When to check the sell_account_rent_receiver

This PR has it set up so that the sell_account_rent_receiver account specified by the solver is only checked if the account is to be closed. Otherwise, any account can be specified. Since duplicated accounts do not count towards the maximum transaction accounts limitation in solana, it means that this feature will not negatively impact the maximum orders in a settlement limit unless the sell token account is actually being closed.

Out of Scope

Since the user would be setting their token CloseAuthority to the settlement account, we should also provide an instruction or similar to recover the close authority back to the owner of the token account. This instruction is not included.

This is not "out of scope", but since it was easy, changes were made to add close account handling to the test cli. See test plan below!

Test Plan

[ ] Confirm suitable test/feature coverage.
[ ] (optional) try it with the test-cli. Follow the test instructions for making a settlement on #52 . As long as the conditions are met, without adding any flags, rent will be returned to the payer account for the order.

[linear-code]

SC-249