Ensure we can rotate pulumi passphrase secrets providers

[stack72]

Fixes: #5452

When the user is requesting to change the secrets provider to a
passphrase provider, we now calculate that has been requested.

This means, we will prompt for a new passphrase for use in encrypting
the stack.

pulumi stack change-secrets-provider passphrase
Enter your passphrase to unlock config/secrets
    (set PULUMI_CONFIG_PASSPHRASE or PULUMI_CONFIG_PASSPHRASE_FILE to remember):
Enter your new passphrase to protect config/secrets:
Re-enter your new passphrase to confirm:
Migrating old configuration and state to new secrets provider
Enter your passphrase to unlock config/secrets
    (set PULUMI_CONFIG_PASSPHRASE or PULUMI_CONFIG_PASSPHRASE_FILE to remember):

Thanks to @pierskarsenbarg for helping to drive through the workflow here!

[justinvp]

After we print Migrating old configuration and state to new secrets provider, why does the user have to re-enter their new passphrase again? Is there any way we could avoid that?

Ideally, the flow would be:

pulumi stack change-secrets-provider passphrase
Enter your passphrase to unlock config/secrets
    (set PULUMI_CONFIG_PASSPHRASE or PULUMI_CONFIG_PASSPHRASE_FILE to remember):
Enter your new passphrase to protect config/secrets:
Re-enter your new passphrase to confirm:
Migrating old configuration and state to new secrets provider

[stack72]

After we print Migrating old configuration and state to new secrets provider, why does the user have to re-enter their new passphrase again? Is there any way we could avoid that?

Ideally, the flow would be:

pulumi stack change-secrets-provider passphrase
Enter your passphrase to unlock config/secrets
    (set PULUMI_CONFIG_PASSPHRASE or PULUMI_CONFIG_PASSPHRASE_FILE to remember):
Enter your new passphrase to protect config/secrets:
Re-enter your new passphrase to confirm:
Migrating old configuration and state to new secrets provider

So the reason the user needs to do that is that they need to unlock the new secrets manager again - we don't (currently) carry the secrets manager out of createSecretsManager to make that change would be a larger diff and would potentially break some areas - we can defo look at that as a follow up

This only happens as part of the passphrase secrets manager. It used to ask twice after the new secrets manager was created (once for config and once for state) but I was able to merge those funcs

[justinvp]

LGTM