Determine which resources are blocking clusterctl move during discovery

[nojnhuh]

What would you like to be added (User Story)?

As a developer I want to better align the process for determining if a resource is blocking a clusterctl move operation with other inputs to increase overall consistency.

Detailed Description

The first iteration of allowing resources to block a clusterctl move operation by #8690 requires at least one extra API call for every resource to determine if the resource is blocking the move. Instead, the initial state could be gathered during the discovery phase which would enable tighter short-circuiting where no extra API calls are required for resources not blocking a move.

Anything else you would like to add?

No response

Label(s) to be applied

/kind cleanup
/area clusterctl

[fabriziopandini]

/triage accepted

echoing here #8690 (comment)

@nojnhuh it would be great to get #9196 implemented before 1.6.0 is cut, because the current implementation is adding an unnecessary extra get for all the objects + the user can wait for x times the timeout for waitMove.

[nojnhuh]

/assign