Add Support for Vault Namespaces

[sardanaaman]

Is your feature request related to a problem? Please describe.
I am not able to identify a method (if one exists) to pass a Vault Namespace to the plugin. Typically, large enterprises segment lines of businesses/business entities using namespaces on Vault that can all have separate logins, auth methods, secret engines etc. Currently, the plugin attempts to login with a PUT to <VAULT_ADDR>/v1/auth/github/login (when using GitHub Token auth, but this applies similarly to other supported auth methods as well) which does not suffice when attempting to hook into a specific Vault namespace.

Describe the solution you'd like
This should be a fairly straightforward addition as far as I can tell. I'd want to see another variable that can be defined in the secret (say VAULT_NS). The login would then need to:

PUT/POST to <VAULT_ADDR>/v1/<VAULT_NS>/auth/github/login

or

PUT/POST to <VAULT_ADDR>/v1/auth/github/login with a header X-Vault-Namespace with value <VAULT_NS>

Retrieval of the secret value from Vault can continue to work the way it does today as the namespace can be passed in as part of the secret path or as a header. The link under the "Additional context" section below presents the different options Vault supports for working with namespaces.

Describe alternatives you've considered
Forking a local copy of the code to pass an additional header X-Vault-Namespace to the API call made to Vault, but would think this would be a beneficial addition to the plugin and more sustainable than maintaining a local fork. Without this capability however, this plugin wouldn't be usable on the several projects I plan to use it on.

Additional context

• https://www.vaultproject.io/docs/enterprise/namespaces#usage

[werne2j]

@sardanaaman All Vault environment variables are supported. They just need to be added to the Repo Server pod. If you look here (https://ibm.github.io/argocd-vault-plugin/config/#full-list-of-supported-parameters) it mentions all Vault environment variables. We might want to make that a little more obvious.

[werne2j]

This Issue #85 and PR #94 should also add a little insight