Several env vars got renamed in
https://github.com/hashicorp/vault/pull/6306. This re-adds support for
those.

Indirectly addresses
https://github.com/hashicorp/consul-template/pull/1233 although they
should still update to the new values.

* ensure dropdown updates selected item

* ensure no duplicate ticks

* handle case where counters are Dates instead of strings so bar chart filters in Storybook

* fix panic generating openapi docs

* fmt

This reverts commit 3439a349.

For the moment with bad wifi this is just taking too, too long. We may
be able to figure out an approach that bind mounts the cache in which
should help drastically.

* Don't run Initialize on plugins on postUnseal

* Add comments explaining that we do not want to initalize

Resolves #7081

Wrapping validation was deferring the function to audit log before
actually checking if we were sealed or standby, and without having the
read lock grabbed.

* upgrade aws roles

* test upgrade aws roles

* Initialize aws credential backend at mount time

* add a TODO

* create end-to-end test for builtin/credential/aws

* fix bug in initializer

* improve comments

* add Initialize() to logical.Backend

* use Initialize() in Core.enableCredentialInternal()

* use InitializeRequest to call Initialize()

* improve unit testing for framework.Backend

* call logical.Backend.Initialize() from all of the places that it needs to be called.

* implement backend.proto changes for logical.Backend.Initialize()

* persist current role storage version when upgrading aws roles

* format comments correctly

* improve comments

* use postUnseal funcs to initialize backends

* simplify test suite

* improve test suite

* simplify logic in aws role upgrade

* simplify aws credential initialization logic

* simplify logic in aws role upgrade

* use the core's activeContext for initialization

* refactor builtin/plugin/Backend

* use a goroutine to upgrade the aws roles

* misc improvements and cleanup

* do not run AWS role upgrade on DR Secondary

* always call logical.Backend.Initialize() when loading a plugin.

* improve comments

* on standbys and DR secondaries we do not want to run any kind of upgrade logic

* fix awsVersion struct

* clarify aws version upgrade

* make the upgrade logic for aws auth more explicit

* aws upgrade is now called from a switch

* fix fallthrough bug

* simplify logic

* simplify logic

* rename things

* introduce currentAwsVersion const to track aws version

* improve comments

* rearrange things once more

* conglomerate things into one function

* stub out aws auth initialize e2e test

* improve aws auth initialize e2e test

* finish aws auth initialize e2e test

* tinker with aws auth initialize e2e test

* tinker with aws auth initialize e2e test

* tinker with aws auth initialize e2e test

* fix typo in test suite

* simplify logic a tad

* rearrange assignment

* Fix a few lifecycle related issues in #7025 (#7075)

* Fix panic when plugin fails to load

Fixing miner typo by adding dot.

- Update sample `payload.json`
- Update sample response

Fixed minor spelling error: sychronized/synchronized.

- Add `--cert` and `--key` options to `curl` example so that it is
  clearer that the certificate and key must also be passed in

plugin docs: update example code snippet with correct imports and link to developing plugin backends tutorial (#6843)
Signed-off-by: hasheddan <georgedanielmangum@gmail.com>

* Fix various read only storage errors

A mistake we've seen multiple times in our own plugins and that we've
seen in the GCP plugin now is that control flow (how the code is
structured, helper functions, etc.) can obfuscate whether an error came
from storage or some other Vault-core location (in which case likely it
needs to be a 5XX message) or because of user input (thus 4XX). Error
handling for functions therefore often ends up always treating errors as
either user related or internal.

When the error is logical.ErrReadOnly this means that treating errors as
user errors skips the check that triggers forwarding, instead returning
a read only view error to the user.

While it's obviously more correct to fix that code, it's not always
immediately apparent to reviewers or fixers what the issue is and fixing
it when it's found both requires someone to hit the problem and report
it (thus exposing bugs to users) and selective targeted refactoring that
only helps that one ...

* core: Don't shutdown if key upgrades fail due to canceled context

* Continue if we are not shutting down

* audit: log invalid wrapping token request/response

* Update helper/consts/error.go
Co-Authored-By: calvn <cleung2010@gmail.com>

* update error comments

* Update vault/wrapping.go
Co-Authored-By: calvn <cleung2010@gmail.com>

* update comment

* move validateWrappingToken out of http and into logical

* minor refactor, add test cases

* comment rewording

* refactor validateWrappingToken to perform audit logging

* move ValidateWrappingToken back to wrappingVerificationFunc

* Fix tests

* Review feedback