Add reusable workflow scripts

[imheresamir]

What does this PR do?

This PR adds end-to-end workflow test scripts, ported over from conjurdemos/kubernetes-conjur-demo
The ported scripts were modified to:

1. Install conjur-oss in a KinD cluster
2. Rework cluster config to use our new helm charts kubernetes-cluster-config and app-namespace-prep
3. Use bitnami/postgresql helm chart for the sample app backend

The app-deploy chart was modified to take enabled flags to select one or more subcharts. The app-summon-sidecar subchart is enabled using --set authn-k8s.enabled=true when installing the parent app-deploy chart.

The workflow can be tested by launching bin/test-workflow/start.

Commit 2 (947fb35) copies unchanged files from conjurdemos/kubernetes-conjur-demo (a4272e3)

Commit 3 (51a92d5) is where the script changes are.

What ticket does this PR close?

Resolves #239 and #301

Checklists

Change log

• The CHANGELOG has been updated, or
• This PR does not include user-facing changes and doesn't require a CHANGELOG update

Test coverage

• This PR includes new unit and integration tests to go with the code changes, or
• The changes in this PR do not require tests

Documentation

• Docs (e.g. READMEs) were updated in this PR, and/or there is a follow-on issue to update docs, or
• This PR does not require updating any documentation

Manual tests

If you are preparing for a release, have you run the following manual tests to verify existing functionality continues to function as expected?

• Manually run Kubernetes-Conjur demo with a local authn-k8s client image build

[diverdane]

This is great stuff!!!
I'm still working my way through this, but here are the comments that I have now.

[diverdane]

More comments. Still plowing through everything.

[doodlesbykumbi]

I think there's a lot of great improvements in the PR. I've left some comments about things that stood out, but I'm still thinking about ways in which we can eradicate the undesirable things that are inherited from the pre-existing scripts.

I think it's good for us to really take that step back and look at this workflow from a high-level, and ask ourselves how we would implement each section given a blank slate. In this case we really do have a blank slate.

A key criteria (for myself) in considering the scripts reusable is for them to be compossible in somewhat arbitrary ways. We are constrained on how granular that decomposition by the logical boundaries of the tasks. I imagine the reusable workflow scripts should allow me to provide input to a script that can carry out any logical task listed in the docs and provide output in a way that could potentially be piped into another script.

[doodlesbykumbi]

This can be introduced as a configmap.

[imheresamir]

Let's discuss and create an issue

[doodlesbykumbi]

NOTE: The PR will require squashing the commits to merge since there's been a lot of back and forth and so the commit history isn't necessary made up of logical units.

Approved, with some follow up issues in mind, here's a rough list

1. Rip out platform branching
2. Revisit platform branching. Helm is great for this, openshift=true  can be used to toggle between openshift and k8s in the spirit of the bitnami postgres chart
3. Update policy loading to match dap-wiki (simpler)
4. Refactor scripts in a way that allows personas to execute steps independent of each other in a way that aligns with dap-wiki
5. Refactor wholesale loading of policy, to allow for loading of policy and writing of variables local to scripts and using the identity of the relevant persona