release-24.2: stats: use available type metadata when hydrating UDTs

[yuzefovich]

Backport 1/1 commits from #137960.

/cc @cockroachdb/release

---

This commit updates the table stats cache to use the correct metadata when hydrating the UDTs for the table stats read from disk. Previously, we would always use the DescsTxn helper to run a separate txn to create the type resolved, which I think meant that we would use latest committed metadata; however, if the UDT modification happened within the current not-yet-committed txn, then we would use stale metadata which could lead to failing an assertion later (that we used enums of different versions). In particular, this would happen if we added a new value to the UDT and then would use the previously-existing value in a filter. Note that we correctly determined that the stats cache entry was stale, we simply used stale type metadata to hydrate the UDTs.

To fix the problem this commit plumbs the type resolver all the way from the caller who is requesting the table stats. The previous behavior is acceptable in some cases (in backups), so the type resolver is optional.

Fixes: #129623.

Release note (bug fix): Previously, CockroachDB could encounter an internal error comparison of two different versions of enum in some cases when a user-defined type was modified within a transaction and following statements read the column of that user-defined type. The bug was introduced in 24.2 version and is now fixed.

Release justification: bug fix.

[blathers-crl]

Thanks for opening a backport.

Please check the backport criteria before merging:

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