Fix a bug with sol_get_processed_sibling_instructions syscall

[wjthieme]

The sol_get_processed_sibling_instructions for the accounts parameter, expects a pointer to an array of AccountMeta (of 34 bytes each, Pubkey + 2x bool). The AccountMeta struct in Pinocchio has a reference to the Pubkey field instead of an owned version of the Pubkey. This results in the Pinocchio AccountMeta struct only being 16 bytes. The syscall fails because of this since it would try to write data beyond the data of the supplied ptr.

This PR adds a RawAccountMeta struct which has an owned version of Pubkey, is therefore 34 bytes long and will work with the syscall.

Other option that should be possible is just define the syscall with *mut [u8] instead of creating this extra struct but imo that makes the syscall more difficult to use (you need to figure out the bytes length yourself).

@febo lmk what you think!

[wjthieme]

For anyone else with this issue (I doubt it 😆). You can make the syscall work by defining a struct yourself and reinterpreting the bytes so the compiler doesn't complain

#[derive(Default, Debug, Clone)]
pub struct AccountMeta {
    pub pubkey: Pubkey,
    pub is_writable: bool,
    pub is_signer: bool,
}

// ...

let mut accounts: Vec<RawAccountMeta> = Vec::new();
let accounts_meta = &mut *(accounts.as_mut_ptr() as *mut AccountMeta);

// ...

pinocchio::syscalls::sol_get_processed_sibling_instruction(
  index,
  &mut meta,
  &mut program_id,
  data.as_mut_ptr(),
  accounts_meta,
);

[febo]

Good point, we need to fix this. We are in the process of sharing types with the SDK (see #111) so the best approach will be to use the AccountMeta from the SDK. But there is a couple of things before we get there, so your workaround is probably the best short term solution.

The current idea is that pinocchio AccountMeta becomes AccountMetaView, so there won't be a name conflict between the SDK's AccountMeta and pinocchio's one.