Audit: explain 'failure' metrics better

[peteski22]

Description

There has been confusion around the vault.audit.log_request_failure and vault.audit.log_response_failure metrics, which are documented as counters.

The metrics emit a number of values that can be checked e.g. count, mean, min... the count for this metric just indicates how many times it was called, however Vault will increment the metric on every success or failure (supplying either the value 0 or 1 respectively). This is done so that systems like Prometheus don't 'forget' the metric if they don't see it fail for a while.

Original PR that calls increment on success or failure

HashiCorp Checklist

• Labels: If this PR is the CE portion of an ENT change, and that ENT change is
  getting backported to N-2, use the new style backport/ent/x.x.x+ent labels
  instead of the old style backport/x.x.x labels.
• Labels: If this PR is a CE only change, it can only be backported to N, so use
  the normal backport/x.x.x label (there should be only 1).
• ENT Breakage: If this PR either 1) removes a public function OR 2) changes the signature
  of a public function, even if that change is in a CE file, double check that
  applying the patch for this PR to the ENT repo and running tests doesn't
  break any tests. Sometimes ENT only tests rely on public functions in CE
  files.
• Jira: If this change has an associated Jira, it's referenced either
  in the PR description, commit message, or branch name.
• RFC: If this change has an associated RFC, please link it in the description.
• ENT PR: If this change has an associated ENT PR, please link it in the
  description. Also, make sure the changelog is in this PR, not in your ENT PR.

[github-actions]

CI Results:
All Go tests succeeded! ✅

[github-actions]

Build Results:
All builds succeeded! ✅

[yhyakuna]

Looks good 👍 Thanks!