Initial master-port of #54039 (support Vault kv version2)

[mchugh19]

What does this PR do?

Attempts to port #54039 to master while adding a unit test for the v2 functionality
This is @thenoid's work to allow salt to support both version 1 and version 2 of Vault's kv secrets backend.

What issues does this PR fix or reference?

See notes on #54039
Also fixes #50186

Previous vs New Behavior

Salt's Vault support really only handled the v1 kv interface. @thenoid's PR added logic to support the correct URLs for both v1 and v2 kv backends.

Vault also changed the return from v1 and v2 kv backends. In v1, secrets were returned. In v2, a data structure is returned like the following:

{'data':
  {'data': 
    {'akey': 'avalue',},
  'metadata':
    {'created_time': '2018-10-23T20:21:55.042755098Z',
     'destroyed': False,
     'version': 13,
     'deletion_time': ''}
  }
}

The secret data that vault.read_secret used to return is now behind another ['data'] lookup. Since this was a change vault-side, this PR does not attempt to retain the old output (maybe users want some of the new data?), and instead publishes what was supplied by vault.

Thus for users on the v1 kv, running a command like vault.read_secret 'secret/super/secret returns a result like: akey: avalue
While users of the v2 kv backend running the same command will get a result like displayed above and will need to walk the returned 'data' key to get the same result.
{% set supersecret = salt['vault'].read_secret('secret/my/secret')['data'] %} (note the trailing 'data')

That said, the execution module's read_secret, and the sdb module's get, both support filtering on the key of the vault secret. So this PR also extends those functions to support the v1 and v2 returns to work as expected when a key is specified.

Tests written?

Yes
There should really be some docs on the docker setup. I tried to run the integration tests locally so I could investigate updating the vault image, and also running a version 2 kv backend for awesome actual tests, but I'm not sure where the vault docker image is being pulled from.
Figured it out! Added module and sdb integration tests with the current version of vault's docker image as it's needed for kv v2 support.

[thenoid]

Thank you for doing the needful and for crediting. <3

[mchugh19]

All green tests! In your face flaky decorator!

[thenoid]

@Ch3LL ???

[Ch3LL]

can you elaborate why we are removing profile here?

[mchugh19]

It is unused in the code. If that's a standard kwarg I'm happy to leave it in.

[mchugh19]

Before merging, it's probably worth discussing the topic brought up in the description. Today with vault kv v1, vault.read_secret 'secret/super/secret returns a result like: akey: avalue
While users of the v2 kv backend running the same command will get a result like displayed above and will need to walk the returned 'data' key to get the same result.
{% set supersecret = salt['vault'].read_secret('secret/my/secret')['data'] %} (note the trailing 'data')

This is done because vault changed the output when using kv v2 to

{'data':
  {'data': 
    {'akey': 'avalue',},
  'metadata':
    {'created_time': '2018-10-23T20:21:55.042755098Z',
     'destroyed': False,
     'version': 13,
     'deletion_time': ''}
  }
}

Where there are separated data and metadata keys. Maybe it makes sense to return data by default, and to have a toggle on metadata?
vault.read_secret /secret/my/path metadata=True

[thenoid]

So with metadata=True it'd return kv2 style {'data': {whatever}, 'metadata': {something}}?

metadata=False it'd be a kv1 style?

I think that's a fair abstraction

Before merging, it's probably worth discussing the topic brought up in the description. Today with vault kv v1, vault.read_secret 'secret/super/secret returns a result like: akey: avalue
While users of the v2 kv backend running the same command will get a result like displayed above and will need to walk the returned 'data' key to get the same result.
{% set supersecret = salt['vault'].read_secret('secret/my/secret')['data'] %} (note the trailing 'data')

This is done because vault changed the output when using kv v2 to

{'data':
  {'data': 
    {'akey': 'avalue',},
  'metadata':
    {'created_time': '2018-10-23T20:21:55.042755098Z',
     'destroyed': False,
     'version': 13,
     'deletion_time': ''}
  }
}

Where there are separated data and metadata keys. Maybe it makes sense to return data by default, and to have a toggle on metadata?
vault.read_secret /secret/my/path metadata=True

[mchugh19]

As described in the comments, the previous behavior of vault.read_secret has been retained. Now read_secret will return the secret data on both kv v1 and v2. Anyone needing to access the full return, can use vault.read_secret /secret/path metadata=True