Eliminate updates to plugins when using Workload Mobility

When creating Virtual System Patterns (VSPs), clients can opt to lock the system plug-ins as documented in the section "Lock option for plugin usage" here.

Clients who deployed Virtual System Instances (VSIs) using Virtual System Patterns that had "Lock option for plugin usage" set to "Unlock plugins" might face some challenges when using Workload Mobility to move those VSIs to another IBM Cloud Pak System. Specifically, the new VSI on the target IBM Cloud Pak System will automatically update all plugins associated with that VSI to the latest version available on the target IBM Cloud Pak System. This results in python code corresponding to those plugins to get updated on the Virtual Machines (VMs) corresponding to the VSI. While differences between plugin versions and their python code are typically small, they do change data on the VMs. However in some cases, the changes are not compatible with the VSI and can lead to middleware roles and services on the VMs of the VSI on the target IBM Cloud Pak System not reaching a RUNNING state (and the VSI as a result would also not reach RUNNING state).

Today IBM recommends to only use VSPs using "Lock option for plugin usage" set to "Lock all plugins" when using Workload Mobility to move the VSIs deployed using those VSPs. That avoids the update of plugins of the VSI as a result of using Workload Mobility. However we believe it would be better if the Workload Mobility feature of IBM Cloud Pak System would ensure that no plugins would get updated, regardless of what "Lock all plugins" was set to in the VSP used to deploy the VSI. This could for example be achieved by introducing a supported mechanism to change an existing VSI such that it would behave as if it was deployed by a VSP using "Lock option for plugin usage" set to "Lock all plugins".