Introduce cluster lock so that solo doesn't allow parallel execution of commands

[jeromy-cannon]

depends on: #569

[leninmehedy]

We should use cluster level lock instead of process lock. Kubernetes provide lease lock, we can use that.

[leninmehedy]

Some notes on locks + solo state:

• Solo state should be versioned and supports migrations
• Locks should be namespace level leases
• Two users should be able to operate against different network deployments aka namespaces simultaneously
• Use the native K8S lease construct
• Look at how the Java or Go Operator SDK implements expirable mutex locks for cluster leadership decisions

[jeromy-cannon]

pulled this from the design doc on multi-cluster, not sure how useful it will be:

# TODO: locking shouldn't be in the config, it should be part of the lease
	lock: # as solo acquires all locks successfully, it should update the solo-state with the metadata so that we can contact the person and override locks if required
		status: true
		expiresAt: 2024-04-25T13:30:32Z
		createdAt: 2024-04-25T13:23:32Z
		contact: [email protected] # person who has the lock
		fromHost: Lenin-RaspberryPi # some sort of host name
		fromIp: 149.167.236.138