Draft: Implement AWS Engine Support for Vault in Gitlab CI

What does this MR do?

The aim of this MR is to support the Vault AWS Secret Engine to inject dynamically AWS secrets into the Gitlab CI Jobs. The MR extends the syntax of all secret engines to support aside from the field key a different and mutually exclusive fields key to return multiple secrets per read operation using a suffix notation - Quoting from the Issue linked below:

job:
  secrets:
    AWS:      # translates to secret `ops/data/production/db`, field `password`
      vault:
        engine:
          name: aws
          path: company-aws
        path: creds/my-role
        fields:
          ACCESS_KEY: access_key
          SECRET_KEY: secret_key 

Would be resolved to:

AWS_ACCESS_KEY=access_key
AWS_SECRET_KEY=secret_key

Steps required

• Implement support for a single secret read to return multiple variables using a suffix notation with backwards compability
• Implement AWS Secret Engine
• (Stretch Goal) Automatically delete credential leases after job is completed as a setting

Why was this MR needed?

The current implementation of Vault secrets only allow to read a single field per read operation, which is not compatible with the AWS Secret Engine in Vault since per read a pair of IAM credentials are generated. See issue linked below for more context.

What's the best way to test this MR?

• Unit tests through mocking of AWS Secret Engine (TBD with second item)
• Manual QA testing with real Vault and AWS account

What are the relevant issue numbers?

• Gitlab Issue: gitlab#298835
• Gitlab MR: Pending