[BUG] Global kv engine version handling affects all requests (breaks transit in particular)

[dsnam]

Describe the bug
The helper methods that transform request paths/parameters to accommodate kv v1 and v2 affect all requests. I am unable to use this driver to make requests to the transit engine without setting .engineVersion(1), but then that would prevent me from using the same instance to interact with a v2 kv store. It seems like it both inserts data into the path, rendering it invalid, and transforms the request object to be nested inside an object with an outer data key.

To Reproduce
Set up a vault server with transit enabled, then use the driver to try to encrypt something without setting engineVersion(1). Seems like the workaround for this bug is enshrined in a test, since you can also just remove the engineVersion value passed into the Vault.create call in TransitApiTest.testTransitEncrypt to see the test fail due to the changes to the url I described above.

[henryx]

As you noticed, vault.logical() helper methods accomodate requests to KVv2 if isn't set engineVersion(1). This because Logical class, for historical reasons, is designed to work correctly with only KV secret, not with other secrets. At the moment, only workaround is use engineVersion(1) before the vault.logical() call. For the future, I'll review entire section