cluster-ui: handle partial response errors on the databases page

[THardy98]

Part of: #102386

Demos (Note: these demos show this same logic applied to both the database details and database table pages as well):
DB-Console

• https://www.loom.com/share/5108dd655ad342f28323e72eaf68219c
• https://www.loom.com/share/1973383dacd7494a84e10bf39e5b85a3

Prior to this change, any query error in the reponse payload for the
databases page would cause the page to render an error. This was
problematic as some queries used to power the databases page directly
query system tables, meaning only ADMIN users could access the page.
This change allows the databases page to handle network responses with
query errors, consequently allowing non-admin users to view the data
they are privy to.

On the databases page, two types of requests are made:

• a single request to fetch all database names
• a request to fetch the database details for each database name

The error handling for these requests has changed as such:

• if we encounter a network or a non size-related query error when
  requesting database names, render a page error
• if we encounter a 'max size' query error when requesting database
  names, render an alert that we're showing partial results
• if we encounter any error requesting a database's details, render a
  Caution icon next to the database's name to indicate there was an
  issue getting results, the Caution icon has a tooltip providing a
  general explanation as to what the issue is
• network errors when fetching database details provide no data for the
  database's table row, consequently the row of statistics for that
  database is unavailable, the network error message is provided in the
  Caution icon tooltip
• query errors when fetching database details are scoped to the row
  cells for that query, which are unavailable
• unavailable cells have a tooltip that highlight the error for that
  cell as well

Note: the change in planner.go allows users to see span statistics for any table, not just tables a user has SELECT privileges for. This is particularly useful for the databases page where users need to see the span statistics for a database, but only have SELECT privileges on a subset of tables. Regardless, span statistics are gated by VIEWACTIVITY, not SELECT privileges.

Release note (ui change): Allow non-admin users to view the databases
page.

[cockroach-teamcity]

This change is 

[maryliag]

On the demo I see the (empty) that we discussed offline about not using, and I don't see it on the code anymore, can you just confirm what it will show on those cases on the UI?
I also added these questions to the videos itself

Reviewed 7 of 12 files at r1, 1 of 1 files at r2, 4 of 4 files at r3, all commit messages.
Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @THardy98)

---

pkg/ui/workspaces/cluster-ui/src/api/sqlApi.ts line 220 at r3 (raw file):

    } else {
      // Otherwise, just log.
      console.error(

here you would log the permission errors, right? This will show up on our datadog and increase our error rate, but this is not necessarily an error if is just permission, because that is the expected behaviour, so you can change to console.warn() when is a permission error, so we can still see if necessary, but doesn't increase our errors rate

[maryliag]

This looks really great!

Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @THardy98)

[THardy98]

On the demo I see the (empty) that we discussed offline about not using, and I don't see it on the code anymore, can you just confirm what it will show on those cases on the UI?

Yes that is the case. I recorded the demo on another branch that didn't capture the empty -> unavailable change I made to this PR. Cells that are unavailable due to being empty with have a tooltip message saying Empty result

[THardy98]

Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @maryliag)

---

pkg/ui/workspaces/cluster-ui/src/api/sqlApi.ts line 220 at r3 (raw file):

Previously, maryliag (Marylia Gutierrez) wrote…

here you would log the permission errors, right? This will show up on our datadog and increase our error rate, but this is not necessarily an error if is just permission, because that is the expected behaviour, so you can change to console.warn() when is a permission error, so we can still see if necessary, but doesn't increase our errors rate

Good point, done.

[maryliag]

Reviewed 1 of 1 files at r4, all commit messages.
Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @THardy98)

[THardy98]

TYFR

[THardy98]

bors r+

[craig]

Build succeeded:

• Bazel Essential CI (Cockroach)

[blathers-crl]

Encountered an error creating backports. Some common things that can go wrong:

1. The backport branch might have already existed.
2. There was a merge conflict.
3. The backport branch contained merge commits.

You might need to create your backport manually using the backport tool.

---

error creating merge commit from d77bee0 to blathers/backport-release-23.1-109245: POST https://api.github.com/repos/cockroachdb/cockroach/merges: 409 Merge conflict []

you may need to manually resolve merge conflicts with the backport tool.

Backport to branch 23.1.x failed. See errors above.

---

_{🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is dev-inf.}