Separate data and leader election DynamoDB tables

[randomvariable]

**Is your feature request related to a problem?
Related to #5045

Describe the solution you'd like
If clients end up in a thundering herd situation and repeatedly issue requests to Vault, eventually write capacity of a DynamoDB table may be exhausted. In this case, the conditional write for leader election cannot occur and the cluster will seal.

Separating the table used for leader election into a separate table ensures that leader election can
always take place even when Vault is overwhelmed by client requests and exceeds available capacity in the DynamoDB table for data.

It may also be worth allowing the audit data into be persisted elsewhere as this will allow caching of reads to work without also exceeding capacity.

Describe alternatives you've considered
Currently considering putting API Gateway in front, or alternate backends.

Explain any additional use-cases
N/A

[ghost]

@randomvariable Do you still use this backend? Do you have thoughts on how we could separate out the table used for leader elections? The backend API appears to be a fairly naive key/value store (with locking and hierarchy), so how would you propose identifying which keys are used for leader elections?

Would using a separate table for locks help the issue? Are locks used for anything other than leader elections? (I'm diving into this code for the first time.)

[vishalnayak]

Issues that are not reproducible and/or have not had any interaction for a long time are stale issues. Sometimes even the valid issues remain stale lacking traction either by the maintainers or the community. In order to provide faster responses and better engagement with the community, we strive to keep the issue tracker clean and the issue count low. In this regard, our current policy is to close stale issues after 30 days. If a feature request is being closed, it means that it is not on the product roadmap. Closed issues will still be indexed and available for future viewers. If users feel that the issue is still relevant but is wrongly closed, we encourage reopening them.

Please refer to our contributing guidelines for details on issue lifecycle.