chained_call_forwarder.rs and the deploy tests in sequencer_core were
added on top of the pre-migration ProgramId-typed ChainedCall/Message/
ProgramInput/ProgramOutput API and didn't conflict during the rebase
since they're new code, so they needed the same field rename/.into()
treatment already applied everywhere else on -3-1.
Adds tests for the remaining execute_deploy failure modes (invalid
bytecode, wrong target account, wrong number of accounts) and a
generic chained_call_forwarder test guest to exercise Deploy invoked
via a chained call rather than only top-level.
The chained-call test is #[ignore]d: it surfaces a real limitation,
not a bug in the test. The forwarding program has to carry the
deployed bytecode through its own instruction_data to build the
chained call, which blows the interpreted 32M-cycle public-execution
cap for any realistically-sized program — the native Deploy fast-path
only covers the loader's own execution, not the caller's. Root cause
is ChainedCall/Message still referencing programs by ProgramId rather
than AccountId, which also means dispatch can't locate a
Deploy-created (PDA-addressed) program at all. Tracked for
marvin/program-as-account-3-1.
BREAKING CHANGE: WrappedTokenConfig and ReceiverConfig gain a governance field and CrossZoneConfig gains source_governance, so the config layouts change and every program image id moves.
Marvin Jones