Secrets refactoring

[freddydk]

With this PR, secrets are refactored kind of what Settings were in #640
Additionally a few bug-fixes were found and included.

ReadSecrets will create an environment variable called Secrets, which contains all requested secrets encoded with base64.
Secrets are no longer created as individual secrets.
All Secrets requested during the call to ReadSecrets will be available in $env:Secrets - empty if the secret doesn't exist.

Part of this refactoring was also to ensure that ReadSecrets and DetermineArtifactUrl didn't have to rewrite the settings environment variable.

ReadSecrets will now determine which secrets are used by AppDependencyProbingPaths and include those in $env:Secrets - and then DownloadProjectDependencies will use the value of the secret to download the dependencies.

ReadSettings in CI/CD will ask for the value of the artifact setting to be read.
DetermineArtifactUrl will now (based on this) determine the artifactUrl and set the environment variable to the "final" value.
RunPipeline will now take artifact as a parameter and use env:artifact as the value.

Additional refactoring, which will be done in separate PRs:

• Split AnalyzeRepo into a series of functions for analyzing specific areas of the repo (to avoid -doNotXXX)
• Use $env:Settings instead of using ReadSettings inside actions
• Add end 2 end tests for delivery and deployment testing the areas, which failed here
• Add end 2 end tests for include in appDependencyProbingPaths
• Add CI test, testing that all actions have a try/catch
• in a few places, secrets are used in yaml files with fromJson(env.Secrets).ghTokenWorkflow - remove this and use $env:secrets inside the action instead

Bugs found during this refactoring:

Unify try/catch for actions

All Actions now have a code snippet in action.yaml, which sets errorpreference and uses try/catch to give good error messages with stack trace. try/catches inside the action.ps1 is only used for telemetry reasons.

DownloadProjectDependencies didn't work for appDependencyProbingPaths

The Download function didn't analyze the settings and used appDependencyProbingPaths as a json structure, which it wasn't. It was always failing, but silently due to a missing multiline symbol in run: in the action.yaml. It might still have worked as RunPipeline itself also was also analyzing appDependencyProbingPaths

Deploy and Deliver didn't work properly after the settings refactoring

After the Settings refactoring, where settings are no longer available as environment variables, Deploy and Deliver was using [System.Environment]::GetEnvironmentVariable to check for settings and secrets - this obviously doesn't work if settings and secrets are no longer individual environment variables.

RunPipeline was requesting wrong secrets

RunPipeline was asking for the StorageContext secret, which it didn't use - instead it needed applicationInsightsConnectionString, which it didn't get. With the new mechanism, we just use secrets.applicationInsightsConnectionString - and if that property is set, we know that we requested the secret.

CalculateArtifactNames were emitting both OUTPUT variables and ENV variables

And in the BuildALGoProject yaml file - some were used as output and some as ENV.
Now only OUTPUT variables are emitted and used all over.
BTW buildMode is output, but it seems like it is never used???

ReadSecrets was called with ghTokenWorkflow=${{ env.GHTOKENWORKFLOWSECRETNAME }}

In multiple places, ReadSecrets was called with ghTokenWorkflow=${{ env.GHTOKENWORKFLOWSECRETNAME }}. The problem is, that the mapping to another secret is done inside ReadSecrets and shouldn't be part of the call. The caller should just ask for GhTokenWorkflow secret and then he should get that secret set from Secrets or Azure KeyVault with whatever name it is mapped to.

[mazhelez]

There're still some low-hanging issues.