As part of introducing better support for 3rd party certificates a new validation flow was suggested, the check is supposed to initialize a test image transfer for a random OVF_STORE in the system and performed a get request to the image transfer ticket info, if the provider certificates are set correct the request will be successful otherwise the user won't be able to perform the action.
Based on the returned response, we were planning to allow/block the addition of a new provider to the system.

After discussing this flow a bit further it was decided that the provider addition is not the best suitable place to perform such an action for some of the following reasons:

1. We don't have enough info in the provider phase to know which OVF_STORE to choose (which SD) while choosing random can cause the test to fail due to lack of permissions even if we have other OVF_STORE that have the right permissions.
2. Due to some temporary state in the system, we can get an error in the flow that will fail the addition of a new provider when it shouldn't.
3. After adding a mutating webhook that retrieve automatically missing engine CA certificate, one of the cases left that can cause failure is missing imageIO cert which is not a supported flow and we don't want to block a provider adding because of that.

Since we still want to inform the user in advance if the migration won't work it was suggested to move this test to be part of a `Plan` flow, when starting a plan we can run this test in the beginning and in the case of failure we can block the migration creation and inform the user that the migration won't work until some issues will be fixed, also at this stage we will have sufficient information regarding the exact SD and disks that will be migrated so can perform a more accurate check.

This PR contains the original logic and can be used as a reference to the feature.