Add Secrets management feature

[pkarw]

Is your feature request related to a problem? If yes, please describe the problem.

Related to #576.

It would be great to have a feature for passing the ENV kind of variables, but safe. It could be passed via the vm context:

const vmContext = { 
secrets:  {
 awsCredentials: { },
 otherSecret: () => { return 'dynamicSecret' }
},

I can imagine that in the AskScripts we could pass these variables as just: secrets.awsCredentials to subsequent resources and functions call, but we can not read these variables. Of course, the resource or function called can somehow return/display/log or another way discredit it. Well, it's a human factor we can't avoid.

[czerwinskilukasz1]

@pkarw

Topic 1. Read.

Let's clarify how the secrets could be read and how they couldn't:

1. read from AskScript variables in AskScript code: NO
2. read from JavaScript variables (objects) in AskScript code (when Let developers to call JS methods on limited JS objects  #580 is implemented): NO
3. read in built-in resources executed by AskVM: YES (otherwise we wouldn't be able to connect to AWS etc.)
4. read in resources created on-the-fly e.g. from JS objects: preferred YES, however I would say it stands in conflict with 1. and 2., so the answer here should be NO

If NO for 4. is OK, I can see an easy way to implement it. Secrets would just be a kind of values that can be accessed only by the AskVM. What we could even do is to instruct AskVM using AskScript how to set the secrets, e.g.: read file secrets.pwd, parse it and store the secrets under key 'my-secrets' in secrets, but won't be able to read them at all.

Let me know what you think.

---

Topic 2. Write (set)

A separate topic is where and how the secrets would be set. Would we store them all in a file? (Plaintext or encrypted). Would we set them programmatically from the code? Would we use ENV variables?

What's your suggestion?

[pkarw]

Hey Łukasz, great study - thank you for your effort. I completely agree. So we could implement the 3rd option for reading the secrets.

In regards to setting the secrets out I suppose we should have kind of async provider overriding the default ENV values. I mean, by default secrets are passed by ENV (+ .env file) but then there's a wrapper around it and it's async function so anyone who'd like to get these from let's say API endpoint can easily extend the secrets provider or replace it with their own implementation