sql: Add database ID to sampled query log

[THardy98]

This change adds a database ID field to the sampled query telemetry log.

Release note (sql change): Sampled query telemetry log includes new
database ID field.

[cockroach-teamcity]

This change is 

[maryliag]

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

[THardy98]

TYFR :)

[THardy98]

bors r+

[craig]

Build succeeded:

• GitHub CI (Cockroach)

[THardy98]

blathers backport 22.1 21.2

[jordanlewis]

Just curious, why do we need this if we already have the database name in the sampled query output?

[kevin-v-ngo]

We wanted to have a stable way to identify a database in telemetry in case it gets renamed. For instance if we're tracking trends at the database-level we'd rely on the ID. I do think it's an edge case for rename and normally we'd track at the cluster level but we never know..

If this change is 'risky' or more effort, happy to defter this until we know exactly what we want answered here.

[jordanlewis]

This change adds risk to the sampling since it requires a lease, along with a new knob that we'd have to educate users about in the case of an emergency: #84429

we require access to descriptors every time we attempt to emit such a log. However, if these descriptors or the leasing mechanism are unavailable, the emission of this log will indefinitely block, greatly impacting the corresponding SQL Session.

Given the edge case nature here, and given that we're about to begin emitting schema telemetry every day that we can join samples against during ETL or after, I'd prefer to see this change reverted unless we can find a way to get the database ID without having to unconditionally grab a lease, which happens if you call GetImmutableDatabaseByName.

The problem is that in some plans, like SHOW session_var or SELECT crdb_internal.some_function(), we might not already have the leased database. And requiring these to lease the database could indeed lead to extra unavailability, which we'd prefer to avoid.

Some possible ways to deal with this:

1. only log the DB ID if the plan we just ran touched the DB (as in ordinary SQL plans)
2. only log the DB ID if the DB descriptor is already cached

For the first idea, we can ask the Queries team for help (perhaps the optimizer's metadata structure caches the database ID when it's used). For the second idea, we can ask the Schema team for help (we don't have an API that checks for entries just in the cache yet, but we could build one).

In the meantime, I think we should revert this change (sorry @THardy98! you couldn't have known about all of this complexity ahead of time).