Remove support for etcd v2 API in storage backends

[tsaarni]

Vault etcd storage backend has an implementation for etcd v2 API. This issue requests removal of v2 API support since the API version is now deprecated in etcd server and will be completely decommissioned by forthcoming etcd v3.6 release.

Additional context

The last etcd2 server release was v2.3.8 on 2017-02-17 (link). Etcd3 has supported both v3 and v2 APIs in parallel and from etcd 3.5 user has needed to add explicit --enable-v2 to enable deprecated v2 API. Release notes also mention (link):

etcd 3.5 is the last version that supports V2 API. Flags --enable-v2 and --experimental-enable-v2v3 are now deprecated and will be removed in etcd v3.6 release.

Backwards compatibility note

Etcd stores user's data in stores that are specific to v2 or v3 APIs. User may run etcd3 server with v2 API option in Vault config file (link) and in this case the data is stored in etcd v2 store. When user changes the value of etcd_api option to v3, or when v2 support is removed from Vault and/or etcd server, that data becomes inaccessible. User would need to do data migration in that scenario.

[aphorise]

Could this make it to 1.9.x?

[tsaarni]

What approach should be taken for the removal:

1. Should there be a deprecation step, and is there example how deprecation should be documented/handled? I assume at least references to v2 in API docs would need to be marked as deprecated, maybe also some warnings in logs should be added?

2. Or could I simply remove the v2 code?

FYI etcd client library uplift is currently blocked by Solaris build #11980 (comment). This applies recent client versions of both v2 and v3.

[ncabatoff]

The deprecation step is happening in #12935.