[WIP] Change logic for generating/loading stack to avoid mismatching key errors

[craddm]

✅ Checklist

• You have given your pull request a meaningful title (e.g. Enable foobar integration rather than 515 foobar).
• You are targeting the appropriate branch. If you're not certain which one this is, it should be develop.
• Your branch is up-to-date with the target branch (it probably was when you started, but it may have changed since then).

🚦 Depends on

⤴️ Summary

When a new stack is created (e.g. during the first run of dsh sre deploy x), a new encrypted key is generated when trying to load the stack and stored in the local workspace used for this run of the function. This doesn't match the project encrypted key.

When an existing stack is selected (such as on a second run of dsh sre deploy x), the project key is used correctly.

The create_or_select_stack function doesn't tell you whether a stack was created or selected. This PR splits select_stack and create_stack separately, catching errors from the stack not existing or already existing respectively. If the stack is being created, then manually overwrite the newly generated key with the existing project key.

An alternative would be to keep the existing create_or_select_stack function and always overwrite the generated key with the project key

Either way, the separate step of checking if the keys match is no longer required, as the keys will always match.

🌂 Related issues

Closes #2249

🔬 Tests

Tested locally

[github-actions]

Coverage report

Click to see where and how coverage changed

File	Statements	Missing	Coverage	Coverage (new stmts)	Lines missing
data_safe_haven/infrastructure
project_manager.py					154-157
Project Total

This report was generated by python-coverage-comment-action

[craddm]

Closing this as issue appears to have been fixed by updating Pulumi CLI to 1.138.0