pkg/cluster: public API methods do not accept context.Context

What would you like to be added:

A context.Context parameter (or an equivalent option) for the public methods on *Provider, at minimum for Create and Delete.

The most backward-compatible approach would be a CreateOption and a DeleteOption that carry the context, similar to how other options are passed today:

func CreateWithContext(ctx context.Context) CreateOption

A more complete approach would be to add context as a first argument to each method directly, which is the standard Go convention for anything that does I/O:

func (p *Provider) Create(ctx context.Context, name string, options ...CreateOption) error
func (p *Provider) Delete(ctx context.Context, name, explicitKubeconfigPath string) error

I understand the second approach is a breaking API change, so I am happy to discuss which direction the maintainers prefer before starting any implementation. I am interested in working on this once there is agreement on the approach.

Why is this needed:

None of the public methods on *Provider accept a context.Context. This means library consumers have no way to cancel or time out a Create call, which can take several minutes. There is also no way to propagate a parent context from an HTTP handler, a CLI signal handler, or a test with a deadline.

The internal exec.Cmder interface already has a CommandContext method, so the plumbing exists at the lowest level. The problem is that there is no way to pass a context from the outside: ClusterOptions has no context field, ActionContext has no context field, and the internal providers.Provider interface methods (Provision, ListClusters, DeleteNodes, and others) do not accept a context either. The waitforready action uses a plain time-based loop with no cancellation path at all.

In practice, library consumers who need cancellation today have to wrap the Create call in a goroutine and use a select on the context, but that does not actually stop the work running inside Create. It just abandons it. That is not a real solution, especially when the operation may be provisioning containers or running kubeadm inside them.

Accepting context.Context is standard practice in Go for any operation that does I/O or long-running work. This is arguably the most fundamental gap in the library API right now.