sqlstats: "get regions for node" logic is extremely inefficient

[knz]

Split from #101299

Describe the problem

This PR #95449 has implemented "storing the regions in which a statement was executed" using some logic that is abusively expensive:

• the computation in getNodesFromPlanner is way too expensive

  • it extracts the full trace recording for the execution, which incurs a memory copy of the entire trace + a sort of the trace evens
  • it calls ExtractNodesFromSpan which calls protoutil.Unmarshal, which incurs a heap allocation and a relatively expensive decode
  • all of which just to store an unordered set of "node IDs" (SQL instance IDs) that the query was using.
  • Observation: this work should be reduced to store the node IDs as separate structured metadata on the traces, and use a dedicated trace accessor function that only collects the SQL instance IDs (into an unordered set), so as to avoid the sort+unmarshaling steps.
  • Additionally: ExtractNodesFromSpan returns an unordered set already (intsets.Fast). Then ForEach converts it into a sequence. Then the caller uses util.CombineUnique to transform the sequence back into a set. This is just silly and these steps should be combined.

• the computation in getRegionsForNode is way too expensive

  • it retrieves all the SQL instances (resolver.GetAllInstances) even though the specific query under consideration might use just 1 of them
    • This should use a different API that only retrieves region details for the instance IDs under consideration
  • it uses an API that performs an internal data transformation (from cache to list, and then sorts the list), incurring CPU overhead, even though this logic does not need all the instance details nor does it need it to be sorted
    • This should use a different API that can retrieve just the region information without extra data transformation.
  • it builds the map from instance to region every time, even though the mapping should change rarely (only when instances are added)
    • The mapping of instances to regions should be cached per node (SQL server), and not re-computed on every query.
  • it sorts the list of regions on every call, even though the ordering is only relevant when the results are observed
    • The computation should not sort at all; instead the sorting should happen in the front-end during presentation

Expected behavior

The code should be refactored overall to remove the excess CPU and memory overheads.

Jira issue: CRDB-27322