Add sys/version-history endpoint and associated command

[ccapurso]

Tracking version history was added in Vault 1.9.0. Version entries are stored in entries keyed by core/versions/<version-string> (e.g. /core/versions/1.9.0). The entries themselves contain the installation timestamp of the version. Originally, the timestamps stored were created using local time (i.e. time.Now()). UTC is preferred and thus the logic has been modified to store new entries using UTC (i.e. time.Now().UTC()). Consistency is achieved by adding self-heal logic upon the initial read to cache existing entries in Core.versionTimestamps. If an existing timestamp's time.Location is not time.UTC then it is modified and rewritten.

The Core.storeVersionTimestamp method originally checked for the existence of an entry for the provided version. If one existed, a write to storage would not occur. The has been modified to take a force argument in order to facilitate the self-heal process.

Note: all of the core/versions logic used to reside in core_util_common.go. This PR has moved it to version_store.go.

Users currently only have the ability to determine the current version of the running Vault. This PR introduces a new authenticated LIST endpoint, sys/version-history, that will return the version history of a Vault cluster. The keys array will contain the versions in chronological order. key_info will include entries indexed by the version strings found in keys with additional information including the previous_version and timestamp_installed.

Example response:

{
  "keys": [
    "1.9.0",
    "1.9.1",
    "1.9.2"
  ],
  "key_info": {
    "1.9.0": {
      "previous_version": null,
      "timestamp_installed": "2021-11-18T10:23:16Z"
    },
    "1.9.1": {
      "previous_version": "1.9.0",
      "timestamp_installed": "2021-12-13T11:09:52Z"
    },
    "1.9.2": {
      "previous_version": "1.9.1",
      "timestamp_installed": "2021-12-23T10:56:37Z"
    }
  }
}

An associated vault version-history CLI command has been added. By default, it will print table output as follows. The raw JSON response can be printed using -format=json.

Note: Version tracking was added in 1.9.0. Earlier versions have not been tracked.

Version   Installation Time
-------   -----------------
1.9.0     2021-11-18T10:23:16Z
1.9.1     2022-12-13T11:09:52Z
1.9.2     2021-12-23T10:56:37Z

[ncabatoff]

Should we also mention that it was only added in 1.10 here? We could also use the seal-status endpoint to detect the server version and not bother with the version-history call if the server is <1.10, but I'm not sure I want to set that precedent.

[ccapurso]

I don't think that I like falling back to the seal-status endpoint either. I think mentioning that the version-history endpoint was added in 1.10 as well makes sense.

[ccapurso]

I didn't add this warning directly to the error handling logic but instead to the existing warning at the top of the CLI output that mentions the earliest version that has been tracked.

See this commit 7417fbb. What do you think?

[ncabatoff]

Typically we put only tests in the http package when they're exercising code that lives in that package, i.e. "non-logical" endpoints.

[ccapurso]

I was trying to follow the example of testing other sys endpoints:

❯ find http -type f -name sys*_test.go
http/sys_rekey_test.go
http/sys_init_test.go
http/sys_version_history_test.go
http/sys_rotate_test.go
http/sys_generate_root_test.go
http/sys_in_flight_requests_test.go
http/sys_lease_test.go
http/sys_policy_test.go
http/sys_monitor_test.go
http/sys_auth_test.go
http/sys_mounts_test.go
http/sys_config_cors_test.go
http/sys_hostinfo_test.go
http/sys_health_test.go
http/sys_metrics_test.go
http/sys_mount_test.go
http/sys_internal_test.go
http/sys_seal_test.go
http/sys_audit_test.go
http/sys_config_state_test.go
http/sys_leader_test.go
http/sys_wrapping_test.go

[ncabatoff]

Some of these are indeed non-logical endpoints, e.g. health, metrics, pprof, monitor. Most of the rest are just ancient tests that we probably wouldn't write this way nowadays. If you look for tests starting with "TestSystemBackend" you'll find a ton of other examples elsewhere that are more conventional.

[ccapurso]

That's great context, thank you! I'll take a look and modify accordingly.

[swayne275]

a few comments but looks good!

[swayne275]

might you want to apply .UTC() to currentTime here, instead of having all calling functions require it?

[ccapurso]

Yup, that's a great point. I'll keep the calls to UTC() in the existing calling code as it doesn't hurt and provides a the example that time.Now().UTC() is preferred over time.Now().

[taoism4504]

Text LGTM