Implicitly charging commit and commit_and_undelegate fees by increasing spent CU

[GabrielePicco]

Description

The current commit CPI includes a payer address (which is currently not used, but was planned to be part of some implementation of #122 )

Current commit cpi used from the clients to integrate in programs:

commit_accounts(
    &ctx.accounts.payer,
    vec![&ctx.accounts.counter.to_account_info()],
    &ctx.accounts.magic_program)?;
Ok(())

which requires to add 2 accounts to a wrapper instruction, going from

#[derive(Accounts)]
pub struct Increment<'info> {
    #[account(mut, seeds = [TEST_PDA_SEED], bump)]
    pub counter: Account<'info, Counter>,
}

to

#[derive(Accounts)]
pub struct IncrementAndCommit<'info> {
    #[account(mut)]
    pub payer: Signer<'info>,
    #[account(mut, seeds = [TEST_PDA_SEED], bump)]
    pub counter: Account<'info, Counter>,
    /// CHECK:`
    pub magic_program: AccountInfo<'info>,
}

Additionally, we may need to add accounts depending on the implementation, as the charging isn't yet implemented.

Improvement proposal

• Implicitly charging the tx fee_payer by consuming CU in the magic_program commit instruction. Every commit will cost an amount of CU, which will cost more lamports to the fee_payer
• Removing the payer:

commit_accounts(
    vec![&ctx.accounts.counter.to_account_info()],
    &ctx.accounts.magic_program)?;
Ok(())

• Hacky way that comes to mind: while loop to consume CU (probably a bad idea)
• Investigate a proper way to consume CU (perhaps with a custom SYS_CALL)

Benefits

This would simplify the integration, remove one accounts from the tx input and additionally reuse SVM standard CU charging instead of implementing something custom (e.g. charging trough a system_transfer)

Notes

• Commits seems to be grouped by "payer": https://github.com/magicblock-labs/magicblock-validator/blob/master/programs/sleipnir/src/schedule_transactions/transaction_scheduler.rs#L47, to investigate as I don't fully understand the rationale