Service / contract tests

[jinal--shah]

I'm tempted to add some assurance tests for the included tools, specifically jq + aws cli - those form the expected contract for future aws_env releases, so we can move to semver and prepare to replace credstash with alternative secrets managers e.g. ssm param store, for v2.x.x

Then again, this container is just a bundle of 3rd party tools which they have already tested ... we don't have any code of our own as such, nor even a docker init entrypoint that might warrant testing.

We still want to avoid the situation though where a bundled tool is removed from the latest version of the image e.g. credstash may be getting dropped now, given AWS has cheaper alternatives e.g. SSM Parameter Store, even Secrets Manager ...

Instead of trying to test sprawling, 3rd party-maintained apps maybe we should version our own bundle semantically.

[jinal--shah]

After discussion with @aries1980 (and previous discussions with @leventyalcin ) we think versioning is the way forward for this.

We'll address testing once we add bespoke code to the image e.g. it will be required when we introduce code to choose between different secrets managers backends for example

[jinal--shah]

TODO:

• add a note to the README that the semver tag must be used in preference to stable from now on.
• consider tagging the docker image with additional major-only and major-minor-only tags as well, to allow consumers to peg to the latest major version, or minor version for a given major. e.g opsgang/aws_env:1.2.2, opsgang/aws_env:1.2, opsgang/aws_env:1 pointing to the same image.