feature gate: add activate instruction

[buffalojoec]

This PR adds the ActivateFeature instruction to the Feature Gate program.

This instruction is the activation process via feature keypair that we are familiar with today.

The next PR in this stack will address this comment on #5510 with an instruction designed for multi-sig support.

[buffalojoec]

Current dependencies on/for this PR:

• master
  • PR feature gate: init program with RevokePendingActivation instruction #5510
    • PR feature gate: add activate instruction #5541 👈
      • PR feature gate: add multisig/authority support to activate instruction #5566
        • PR feature gate: add revoke with authority instruction #5567

This comment was auto-generated by Graphite.

[CriesofCarrots]

If possible, I think we should continue to support the current process, where a single signer is the feature account, so that we can upgrade to this version of the program without making engs immediately change process to having to derive an address to put in the feature_set list. Make authority optional and only derive the address when Some?

[buffalojoec]

If possible, I think we should continue to support the current process, where a single signer is the feature account, so that we can upgrade to this version of the program without making engs immediately change process to having to derive an address to put in the feature_set list. Make authority optional and only derive the address when Some?

Yeah that's totally possible!

I'm going to re-write this PR to be the activate instruction as we currently know it, so nothing changes for contributors. Then I'll introduce another with the multi-sig support and we can check them both out in tandem.

[CriesofCarrots]

I think we should move transfer handling into process_activate_feature(). That way we can use the Rent syscall to be sure we're using correct rates. Rent::default() may not always be accurate.
Would be something like what we do in spl-assocated-token:

solana-program-library/associated-token-account/program/src/tools/account.rs

Lines 28 to 42 in 5ce6eac

	let required_lamports = rent
	.minimum_balance(space)
	.max(1)
	.saturating_sub(new_pda_account.lamports());
	if required_lamports > 0 {
	invoke(
	&system_instruction::transfer(payer.key, new_pda_account.key, required_lamports),
	&[
	payer.clone(),
	new_pda_account.clone(),
	system_program.clone(),
	],
	)?;
	}

Unless there's a reason I'm missing that the transfer needs to be separate?

[buffalojoec]

I was following Token2022's example with how account initialization is handled, specifically initializing token metadata:

solana-program-library/token/client/src/token.rs

Lines 3614 to 3637 in acabef3

	pub async fn token_metadata_initialize<S: Signers>(
	&self,
	update_authority: &Pubkey,
	mint_authority: &Pubkey,
	name: String,
	symbol: String,
	uri: String,
	signing_keypairs: &S,
	) -> TokenResult<T::Output> {
	self.process_ixs(
	&[spl_token_metadata_interface::instruction::initialize(
	&self.program_id,
	&self.pubkey,
	update_authority,
	&self.pubkey,
	mint_authority,
	name,
	symbol,
	uri,
	)],
	signing_keypairs,
	)
	.await
	}

solana-program-library/token/client/src/token.rs

Lines 3657 to 3695 in acabef3

	pub async fn token_metadata_initialize_with_rent_transfer<S: Signers>(
	&self,
	payer: &Pubkey,
	update_authority: &Pubkey,
	mint_authority: &Pubkey,
	name: String,
	symbol: String,
	uri: String,
	signing_keypairs: &S,
	) -> TokenResult<T::Output> {
	let token_metadata = TokenMetadata {
	name,
	symbol,
	uri,
	..Default::default()
	};
	let additional_lamports = self
	.get_additional_rent_for_new_metadata(&token_metadata)
	.await?;
	let mut instructions = vec![];
	if additional_lamports > 0 {
	instructions.push(system_instruction::transfer(
	payer,
	&self.pubkey,
	additional_lamports,
	));
	}
	instructions.push(spl_token_metadata_interface::instruction::initialize(
	&self.program_id,
	&self.pubkey,
	update_authority,
	&self.pubkey,
	mint_authority,
	token_metadata.name,
	token_metadata.symbol,
	token_metadata.uri,
	));
	self.process_ixs(&instructions, signing_keypairs).await
	}

But in hindsight I'm thinking that might be the process for some of the Token2022 stuff since the account in question may or may not exist prior to the instruction (?).

Considering these feature accounts will not exist prior to sending the instruction, and our CLI command solana feature activate will always use the "with rent" one, I think it makes sense to combine in the program's processor, yep.

[buffalojoec]

Note this also requires a payer though

[buffalojoec]

I've added a commit for this. If we decide we don't like it I can always pluck it!

[buffalojoec]

Closing for now, since whenever SIMD talks conclude, we'll want to upgrade the program one feature at a time, starting with the existing RevokePendingActivation instruction.