MachinePools cannot be upgraded atomically when used with managed providers

**What steps did you take and what happened:**
Many providers have built their managed node pool based on CPI machinepools. In most cases, customers can provide a custom vm image to be used by the node pool. for example here - https://github.com/oracle/cluster-api-provider-oci/blob/63f38727a6fba8ef78668fcb8187922ddf3cbfa8/exp/api/v1beta1/ocimanagedmachinepool_types.go#L180

The nodepool version is take from the machinepool spec like follows MachinePool.Spec.Template.Spec.Version.

This results in an inability to upgrade the machinepool(node pools) atomically. Because if we have to upgrade the kubernetes version, the version in CAPI MachinePool spec as well as the custom image infrastructure machinepool spec has to be changed and since they are in different objects, they cannot be changed atomically.

**What did you expect to happen:**

Machinepools can be upgraded tomically.

**Anything else you would like to add:**
[Miscellaneous information that will assist in solving the issue.]

**Environment:**

- Cluster-api version:
- minikube/kind version:
- Kubernetes version: (use `kubectl version`):
- OS (e.g. from `/etc/os-release`):

/kind bug
[One or more /area label. See https://github.com/kubernetes-sigs/cluster-api/labels?q=area for the list of labels]

Start by tracing how MachinePool.Spec.Template.Spec.Version is consumed and read the referenced exp/api/v1beta1/ocimanagedmachinepool_types.go definition in the Oracle provider. Compare the CAPI MachinePool spec with the managed provider’s infrastructure MachinePool spec and determine what change would allow Kubernetes version and custom image upgrades to be applied atomically.

Written by the indexing model from the issue text.