Create LogicalKVv2 type

[ianferguson]

Setting the entire Vault client to "v1" or "v2" to handle the differences in the KVv1 and KVv2 Vault APIs works well enough for use cases where users only use a KV mount and the version of the KV mounts used in the target Vault cluster are homogeneous.

I think its worth deprecating that as a "driver" level feature and replacing it with:

• a LogicalKVv2 type returned from Vault
• the ability to configure Logical to optionally use Vault's (not fully documented) /sys/internal/ui/mounts/* preflight check endpoints to auto-detect the logical version to use, for use cases where the user is expected to have permission to access those and the extra round trip call to vault is acceptable in exchange for transparently negotiating KV v1 vs v2 mounts

This should give a better user experience and avoid frequent confusion with non KV mounts being used alongside KVv2 mounts in the same Vault instance such as:

• Using Transit service doesn't work for anything other than engine Version 1 BetterCloud/vault-java-driver#234
• Vault transit fails when engineVersion set to 2 BetterCloud/vault-java-driver#231

Related To:

• Handling KVv2 and custom mount paths like official vault CLI tooling BetterCloud/vault-java-driver#202

TBD:

• Should the mount map constructor also be deprecated and phased in in a later major version? I think so -- we don't pass a map of database backends or PKI secret backends, they are just interacted with directly using the API types returned by the Vault type -- KVv1 vs KVv2 mounts can be handled via API types too, rather than a special case map