sql: tolerate non-SQL keys in AddContentionEvent

[tbg]

Describe the problem

contentionRegistry.AddContentionEvent currently assumes that all keys passed to it are SQL keys. This is not true, as evidenced by this test failure in acceptance/multitenant:

| ERROR: ensuring SQL migrations: failed to run migration "alter scheduled jobs": alter-scheduled-jobs: polling for queued jobs to complete: poll-show-jobs: unable to add contention event to registry: invalid uvarint length of 9

To Reproduce

Run acceptance/multitenant with a version of (*DistSQLReceiver).Push that does not throw away errors from AddContentionEvent.

Expected behavior
I would expect the contention registry to handle such keys gracefully. It could either ignore them, but it's likely worth looking into whethercontention on non-SQL keys should be tracked (since the error above results from a SQL operation).

Environment:

• first observed on tracing: propagate non-recording spans across rpc boundaries #59992 (which added a quick fix to ignore the error and resulted in filing this issue)

[asubiotto]

We should also panic with any AddContentionEvent errrors in test builds. Hoping that @yuzefovich can take a look at this as part of his other contention work.