Feat: Remove state and encryption key on sst remove

[jamesgibbons92]

Closes #5617

This PR adds a state config prop purgeOnRemove to the sst config.
When true, the state file, encryption key and secrets related to the stage are deleted from s3 and ssm.
This replicates the same behaviour as pulumi destroy --remove and cleans up unused passphrases and objects in s3.
This is default false to maintain backwards compatibility.

  app(input) {
    return {
      name: "sst-debug-test",
      removal: input?.stage === "production" ? "retain" : "remove",
      home: "aws",
      providers: {
        aws: {
          region: "eu-west-1",
        },
      },
      state: {
        purgeOnRemove: true,
      },
    };
  },

[vimtor]

@jamesgibbons92 is this related to #6097?

i like the --purge flag approach a lot better

[jamesgibbons92]

@vimtor Yeh similar, as part of this PR I am also remove the app/stage.json state file.

[jamesgibbons92]

There is 1 minor issue I need to look into this PR still, if you run sst remove --purge it correctly removes everything (state files, ssm parameter).
However if I run sst remove again, I get "Stage not found" which is correct and expected - however this command is creating an SSM passphrase for the stage, even though we aren't deploying a new stage. There seems to be a getOrSet type method being called which is always initialising the passphrase if it doesn't exist, probably in the boostrap process. Need to check if we can change this so it only creates the passphrase if we're deploying a new stack.

[vimtor]

related to #6669 (comment) and #6576 (comment)

do you think it could make sense to expose this as a config like this:

export default $config({
  app(input) {
    return {
      name: "my-sst-app",
      home: "aws",
      state: {
        retention: 30,
        compress: true,
        purgeable: true // or a better name 
      }
    };
  },
});

[jamesgibbons92]

makes sense if were exposing more configuration options for the state management this way, I was going to implement it this way initially but opted for arg as it was easier at the time. happy to update this when that state config handling lands

[jamesgibbons92]

@vimtor I added the config for this, it was fairly straightforward.

one thing this PR does not do is clean up the object versions, maybe this would be covered by #6669 ?

[jamesgibbons92]

@vimtor just wondering actually, should we put this config in the home prop, kinda makes more sense as this is related to where the state is stored. it would be a union type so you could have either

   home: "aws"

or

  home: {
    "provider": "aws",
    "purgeOnRemove": true
  }

[vimtor]

i'm thinking maybe we do this:

state: {
  store: "aws",
  purgeOnRemove: false,
  // etc...
}

and deprecate home in the next major