release-24.2: ui: use status server apis for stmt bundle ops

[xinhaoz]

Backport 2/2 commits from #128856.

/cc @cockroachdb/release

Release justification: bug fix

---

Since 23.1 we've been using the sql over http api to view, request and cancel stmt bundles for fingerprints. This caused a regression in the sql permissions required to use these features. Prior to using sql over http we only required VIEWACTIVITY or VIEWACTIVITYREDACTED for these operations. Now VIEWSYSTEMTABLE is also required since the sql over http api direclty reads from system.statement_diagnostics_requests as the db console user.

Instead of creating a view and builtins on top of the system table, let's simply revert to the existing http apis on the status server that is already properly gated.

This change reintroduces the following APIs to DB Console

• POST /_status/stmtdiagreports to request statement bundles
• GET /_status/stmtdiagreports to list statement bundles
• POST /_status/stmtdiagreports/cancel to cancel statement bundles

Limitations: This PR does not carry over the added behaviour in 23.1 where we prevent users from making multiple statement bundle reqs for a particular fingerprint. This is not really a common case in the UI since we show 'Waiting' in the overview page for the row when a stmt bundle is in progress for a fingerprint.

Epic: none Fixes: #121301

---

ui/e2e: add e2e testing for statement bundles

This commit adds some e2e cypress tests for statement bundle features in DB Console:

• add tests for requesting, cancelling and viewing bundles for privileged (VIEWACTIVITY, ADMIN) and non-privileged users
• reformat cypress login command to use a new users fixture that defines users by sql privilege
• add cypress command getUserWithExactPrivileges which retrieves users from the fixture with the provided privileges

Release note: None

Part of: https://github.com/cockroachdb/cockroach/issues/121301

[blathers-crl[bot]]

Thanks for opening a backport.

Please check the backport criteria before merging:

• [x] Backports should only be created for serious issues or test-only changes.
• [x] Backports should not break backwards-compatibility.
• [x] Backports should change as little code as possible.
• [x] Backports should not change on-disk formats or node communication protocols.
• [x] Backports should not add new functionality (except as defined here).
• [x] Backports must not add, edit, or otherwise modify cluster versions; or add version gates.
• [x] All backports must be reviewed by the owning areas 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 

[xinhaoz]

Local testing: https://github.com/user-attachments/assets/193f32c2-64f3-44c7-999e-85be24e612a6