p-token: Add unwrap_lamports instruction

[febo]

Problem

In order to transfer out lamports from native SOL accounts, currently it is necessary to create and close ATAs or token accounts all the time.

Solution

This PR adds a new unwrap_lamports instruction that allows transferring out lamports directly to any destination account. This eliminates the need for creating temporary native token accounts for the recipient.

The new instruction uses the discriminator 3945, which is currently unused in Token-2022.

The amount to unwrap is specified as an Option<u64>:

• None: the entire token balance is unwrap
• Some(amount): the specified amount is unwrap

[joncinque]

This looks good to me! Just the bit on the discriminator. Also, be sure to get someone like @Arrowana to make sure it does what they need.

[Arrowana]

This looks good to me! Just the bit on the discriminator. Also, be sure to get someone like @Arrowana to make sure it does what they need.

It looks ok, but should it have a feature similar to close, allowing unwrapping the entire available amount?

I see a few use cases for this unwrap_lamports:

• A program which wants to support unwrapping, this PR already works then.
• User interface / sdk which add convenience, in which case they call a program that might produce a variable amount, so amount is not fixed at execution but it should really unwrap all when they call it.

[febo]

This looks good to me! Just the bit on the discriminator. Also, be sure to get someone like @Arrowana to make sure it does what they need.

Ir looks ok, but should it have a feature similar to close it allows unwrapping the entire amount?

I see a few use cases for this:

• A program which wants to support unwrapping, this PR already works then.
• User interface / sdk which add convenience, in which case they call a program that might produce a variable amount, so amount is not fixed at execution but it should really unwrap all when they call it?

So would it make more sense to always unwrap the entire amount or have both options?

[Arrowana]

This looks good to me! Just the bit on the discriminator. Also, be sure to get someone like @Arrowana to make sure it does what they need.

Ir looks ok, but should it have a feature similar to close it allows unwrapping the entire amount?
I see a few use cases for this:

• A program which wants to support unwrapping, this PR already works then.
• User interface / sdk which add convenience, in which case they call a program that might produce a variable amount, so amount is not fixed at execution but it should really unwrap all when they call it?

So would it make more sense to always unwrap the entire amount or have both options?

both options

[febo]

This looks good to me! Just the bit on the discriminator. Also, be sure to get someone like @Arrowana to make sure it does what they need.

Ir looks ok, but should it have a feature similar to close it allows unwrapping the entire amount?
I see a few use cases for this:

• A program which wants to support unwrapping, this PR already works then.
• User interface / sdk which add convenience, in which case they call a program that might produce a variable amount, so amount is not fixed at execution but it should really unwrap all when they call it?

So would it make more sense to always unwrap the entire amount or have both options?

both options

@Arrowana PR updated.

[buffalojoec]

Implementation lgtm, just left a few comments about the tests!

[buffalojoec]

Lgtm from my side!

[joncinque]

Just a tiny thing

The base branch was changed.