Adds StackChangeSecretsProvider to Go automation api

[Frassle]

Description

Fixes #14035.

Checklist

• I have run make tidy to update any new dependencies
• I have run make lint to verify my code passes the lint check
  • I have formatted my code using gofumpt

• I have added tests that prove my fix is effective or that my feature works

• I have run make changelog and committed the changelog/pending/<file> documenting my change

• Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version

[pulumi-bot]

Changelog

[uncommitted] (2023-11-21)

Features

• [auto/go] Add ChangeSecretsProvider to workspace and stack APIs.
  #14039

[justinvp]

Nit: Rather than prefixing with Stack, I am wondering if this should be ChangeStackSecretsProvider. We have other stack operations around tags and import/export that aren't prefixed with Stack.

Also, wondering if we should expose a ChangeSecretsProvider on stack as well as a convenience.

[justinvp]

stdin string

I don't love calling this stdin. If eventually we move away from a CLI-backed implementation under the covers, I'm not sure what stdin even means anymore.

Also, what happens for the secret providers that don't need a value supplied to stdin? I assume I just pass an empty string in that case, but it's not immediately obvious from the parameter name that it's optional in that way.

I'm wondering if instead we should have something like:

type ChangeStackSecretsProviderOptions struct {
	// NewPassphrase is the new passphrase when changing to a `passphrase` provider
	NewPassphrase *string
}

ChangeStackSecretsProvider(ctx context.Context, stackName, newSecretsProvider string,
	opts *ChangeStackSecretsProviderOptions) error

Where nil can be passed for the last parameter if not opts are needed.

Usage:

s.Workspace().StackChangeSecretsProvider(ctx, s.Name(), "default", nil)

newPassphrase := "newpassphrase"
s.Workspace().StackChangeSecretsProvider(ctx, s.Name(), "passphrase", &auto.ChangeStackSecretsProviderOptions{
	NewPassphrase: &newPassphrase,
})

I could also imagine some alternative variants:

// 1. Single method with opts
ChangeStackSecretsProvider(ctx context.Context, stackName, newSecretsProvider string,
	opts *ChangeStackSecretsProviderOptions) error

// 2. Single method with newPassphrase
ChangeStackSecretsProvider(ctx context.Context, stackName, newSecretsProvider string,
	newPassphrase *string) error

// 3. Multiple methods, one without opts, one with opts
ChangeStackSecretsProvider(ctx context.Context, stackName, newSecretsProvider string) error
ChangeStackSecretsProviderWithOptions(ctx context.Context, stackName, newSecretsProvider string,
	opts *ChangeStackSecretsProviderOptions) error

// 4. Single method with opts based on functional args pattern
ChangeStackSecretsProvider(ctx context.Context, stackName, newSecretsProvider string,
	opts ...optchangesecretsprovider.Option) error

1 or 2 would be my preference.

[Frassle]

Also, wondering if we should expose a ChangeSecretsProvider on stack as well as a convenience.

Yes, but that will just be a passthrough to this method like most of the other Stack methods.

I don't love calling this stdin

Likewise. This gets even worse if we start supporting more secret providers which might need even more complicated setup than just a single new passphrase.

// 1. Single method with opts

I think this is my preference. It makes it possible for us to extend this with more options later if needed.

[justinvp]

Let's go with the naming and signature for (1) and also add a ChangeSecretsProvider method on Stack in stack.go that calls through to the workspace method.

[Frassle]

GitHub UI doesn't seem to be catching up with the commits on the branch. I'll give it a bit but we might need to close and re-create this PR.

[justinvp]

LGTM