Patch: Fix patches that incorrectly depend on cluster member being leader

[roosterfish]

This PR is a follow up on #13162 to fix the leader election also for patchStorageRenameCustomISOBlockVolumes and patchStorageUnsetInvalidBlockSettings.

A new function selectedPatchClusterMember is added which offers a deterministic approach to select a single member across the cluster which is eligible to apply the patch. For example this is necessary for the patch patchStorageRenameCustomISOBlockVolumes which interferes with the storage subsystem.

The patch patchStorageUnsetInvalidBlockSettings is superseded by a single idempotent query that can now run multiple times on all cluster members.

[roosterfish]

@tomponline do you want me to fix it also for patchDBNodesAutoInc or should we leave it there for historical reasons since it's not affected by the bug?

I put the reworked patches alongside there parents to keep them together and not at the end of the file.

[tomponline]

@tomponline do you want me to fix it also for patchDBNodesAutoInc or should we leave it there for historical reasons since it's not affected by the bug?

No, lets leave that one well alone.

[tomponline]

The patches var definition says:

Only append to the patches list, never remove entries and never re-order them.

[roosterfish]

The patches var definition says:

Only append to the patches list, never remove entries and never re-order them.

Mhh ok haven't seen this, it felt wrong doing it but I thought if the original patch gets emptied out, and its replacement is executed at the end of the list, maybe it might cause side effects with other patches.