Sealevel: basic tooling to deploy IGPs and configure them with gas oracle data

[tkporter]

Blocked by #2217

The CLI should have the ability to:

• Deploy an IGP (maybe in the core deploy command?)
• Configure gas oracle data on IGPs
• Configure gas overhead amounts for overhead IGP

[tkporter]

Don't have tons of time rn so I'll revisit with more info

General idea is sealevel/client is this big ugly CLI built for deploying programs and interacting with them that uses Clap. We have deploy core, which takes in which env to use, whether the existing keys should be used, etc. It deploys and initializes the Mailbox, ValidatorAnnounce, and MultisigIsmMessageId ISM, and then writes their program IDs to a file called program-ids.json. You can poke around sealevel/environments and look at the commands that the e2e tests run to connect some of the dots.

First step would be to build off #2574 (which adds the new IGP program), so that deploy core also deploys the IGP program.

In addition to deploying, we'll want to initialize the program. This is done by calling the Init instruction, like it's done here in the functional tests:

hyperlane-monorepo/rust/sealevel/programs/interchain-gas-paymaster/tests/functional.rs

Lines 64 to 90 in 25d915a

	async fn initialize(
	banks_client: &mut BanksClient,
	payer: &Keypair,
	) -> Result<(Pubkey, u8), BanksClientError> {
	let program_id = igp_program_id();
	let (program_data_key, program_data_bump_seed) =
	Pubkey::find_program_address(igp_program_data_pda_seeds!(), &program_id);
	// Accounts:
	// 0. [executable] The system program.
	// 1. [signer] The payer account.
	// 2. [writeable] The program data account.
	let init_instruction = Instruction::new_with_borsh(
	program_id,
	&IgpInstruction::Init,
	vec![
	AccountMeta::new_readonly(system_program::id(), false),
	AccountMeta::new_readonly(payer.pubkey(), true),
	AccountMeta::new(program_data_key, false),
	],
	);
	process_instruction(banks_client, init_instruction, payer, &[payer]).await?;
	Ok((program_data_key, program_data_bump_seed))
	}

. Take a look at the logic elsewhere in the sealevel/client for how we send transactions and initialize other programs. Note you won't be able to use the function I linked to directly because the client banks_client: &mut BanksClient, that's passed in there is strictly a test thing. But the general idea of getting the "program data PDA account" here

hyperlane-monorepo/rust/sealevel/programs/interchain-gas-paymaster/tests/functional.rs

Line 70 in 25d915a

let (program_data_key, program_data_bump_seed) =

and creating the instruction with those specific accounts will be the same

Useful links: everything in "Core Concepts" here https://solanacookbook.com/

[tkporter]

I hacked this together for Dan to unblock him on his IGP indexing: #2584
It will:

• deploy the IGP program
• initialize it
• initializes an "IGP account", which relates to a single relayer
• sets gas oracles for a hardcoded domain
• sends a gas payment (this part isn't necessary to keep, because the transfer-remote bit will do this)

I think the changes to that should now be:

1. In core deploy, take in gas oracle configs and set them. This can be a file or something, like one that's expected to live in the rust/sealevel/environments/<env>/ directory. But we should be able to set gas oracle configs for many domains
2. In core deploy, also initialize an Overhead IGP. Lmk if you need pointers here - it works similar to the IGP initialization. You can see how it's done in the tests to initialize an overhead IGP here as a reference. Hardcoding the salt to a constant or something in the core deploy logic feels reasonable to me imo -- atm it's just using H256::zero() as a salt (the salt is so that there can be multiple "IGP accounts"), which we can keep
3. The program IDs that are written should probably be: igp_program_id, overhead_igp_account, and igp_account. I.e. no need for the program data one, and add the overhead IGP one
4. Also in core deploy, we should be able to set the overhead IGP gas amounts. See tests as a reference. Happy to chat about these instructions and how to use them, it's very solana specific in what accounts are expected to pass in etc. But same idea as (1) - should read these from a file (same file maybe?) and be able to set the remote domain's gas overhead