v1.18: Ensure mapping of callee is updated with direct mapping (backport of #1093)

[mergify]

Consider this scenario:

• Program increases length of an account
• Program start CPI and adds this account as a read-only account
• In fn update_callee_account() we resize account, which may change the pointer
• Once CPI finishes, the program continues and may read/write from the account. The mapping must be up-to-date else we use stale pointers.

Note that we always call callee_account.set_data_length(), which may change the pointer. In testing I found that resizing a vector from 10240 down to 127 sometimes changes its pointer. So, always update the pointer.

Problem

Summary of Changes

Fixes #

---

This is an automatic backport of pull request #1093 done by [Mergify](https://mergify.com).

[mergify]

Cherry-pick of cd7f34e has failed:

On branch mergify/bp/v1.18/pr-1093
Your branch is up to date with 'origin/v1.18'.

You are currently cherry-picking commit cd7f34ecfc.
  (fix conflicts and run "git cherry-pick --continue")
  (use "git cherry-pick --skip" to skip this patch)
  (use "git cherry-pick --abort" to cancel the cherry-pick operation)

Changes to be committed:
	modified:   programs/bpf_loader/src/syscalls/cpi.rs
	modified:   programs/sbf/rust/invoke/src/instructions.rs
	modified:   programs/sbf/tests/programs.rs

Unmerged paths:
  (use "git add <file>..." to mark resolution)
	both modified:   programs/sbf/rust/invoke/src/lib.rs

To fix up this pull request, you can check it out locally. See documentation: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally

[seanyoung]

• The non-direct mapping code path is unchanged.
• We would like to enable direct mapping on testnet as soon as
• This change is needed to enable direct mapping on testnet

[willhickey]

This change is needed to enable direct mapping on testnet

Testnet will adopt v2.0 (what is currently master) soon (hopefully within a week or two). I think this warrants backporting anyway, but the testnet direct mapping won't be blocked if we don't

[sakridge]

This change is needed to enable direct mapping on testnet

Testnet will adopt v2.0 (what is currently master) soon (hopefully within a week or two). I think this warrants backporting anyway, but the testnet direct mapping won't be blocked if we don't

Yes, this can be tested with v2.0 so I'm inclined to have it just wait for that and not risk 1.18.