release-23.2: kv: include locking strength and durability in Get/Scan/RevScan SafeFormat

[blathers-crl]

Backport 2/2 commits from #114481 on behalf of @lyang24.

/cc @cockroachdb/release

---

kv: include locking strength and durability in Get/Scan/RevScan SafeFormat

The goal of this pr is improving observability. We are adding lock strength
and lock durability with Get/Scan/RevScan request if the request is locking.
This is implemented by introducing an optional extension interface to Request
Interface called SafeFormatterRequest. We are also refactoring inside
BatchRequest.SafeFormat with the added interface. Please note the subtle
changed introduced here: if the EndKey is not present we print only Key with
square brackets, and this applies to all the request types.

Fixes: #114475
Release note: None.

---

Release justification: low-risk improvement to observability needed for read committed isolation.

[blathers-crl]

Thanks for opening a backport.

Please check the backport criteria before merging:

• Backports should only be created for serious
  issues or test-only changes.
• Backports should not break backwards-compatibility.
• Backports should change as little code as possible.
• Backports should not change on-disk formats or node communication protocols.
• Backports should not add new functionality (except as defined
  here).
• Backports must not add, edit, or otherwise modify cluster versions; or add version gates.
• All backports must be reviewed by the owning areas TL and one additional
  TL. For more information as to how that review should be conducted, please consult the backport
  policy.

If your backport adds new functionality, please ensure that the following additional criteria are satisfied:

• There is a high priority need for the functionality that cannot wait until the next release and is difficult to address in another way.
• The new functionality is additive-only and only runs for clusters which have specifically “opted in” to it (e.g. by a cluster setting).
• New code is protected by a conditional check that is trivial to verify and ensures that it only runs for opt-in clusters. State changes must be further protected such that nodes running old binaries will not be negatively impacted by the new state (with a mixed version test added).
• The PM and TL on the team that owns the changed code have signed off that the change obeys the above rules.
• Your backport must be accompanied by a post to the appropriate Slack
  channel (#db-backports-point-releases or #db-backports-XX-X-release) for awareness and discussion.

Also, please add a brief release justification to the body of your PR to justify this
backport.

[cockroach-teamcity]

This change is 

[michae2]

Reviewed 6 of 6 files at r1, 3 of 3 files at r2, all commit messages.
Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @lyang24 and @nvanbenschoten)

[michae2]

Are all of the changes protected via a flag or option, new syntax, an environment variable or default-disabled cluster setting?

The changes only come into affect when tracing a query.

What are the risks to backporting this change? Can the risks of backporting be mitigated? What are the risks to not backporting?

Risks to backporting: a bug in this code might cause a traced query to fail.
Risks to not backporting: difficulty understanding which rows are locked when examining a trace during a support escalation.

Does this change really need to be backported? Or can it reasonably wait until the next major release to be addressed?

23.2 will have major changes to row locking, and this change increases our observability of that row locking. I think there's a good chance we will need it during a support escalation.

[github-actions]

Reminder: it has been 3 weeks please merge or close your backport!

[michae2]

Rebased on release-23.2. I'll merge once tests are green.

[michae2]

Failure is unrelated flake #116037. Merging.