opt: improve histogram intersection logic for non-numeric types

[DrewKimball]

When a filter on a non-numeric type (string, bytes, uuid, inet) intersects a histogram bucket, it is desirable to estimate a number of rows less than the total number in the bucket. Currently, the logic that handles this assumes a uniform distribution of data values across the first 8 bytes (ignoring any common prefix):

cockroach/pkg/sql/sem/tree/datumrange/range.go

Lines 180 to 182 in 3209e33

	case types.StringFamily, types.BytesFamily, types.UuidFamily, types.INetFamily:
	// For non-numeric types, convert the datums to encoded keys to
	// approximate the range. We utilize an array to reduce repetitive code.

This likely works well for UUID columns, but can cause catastrophic underestimates for STRING columns, which are often clustered around certain values. A common example is when the STRING column represents a path. We should consider relaxing the uniformity assumption for non-UUID types.

Jira issue: CRDB-57841

[blathers-crl]

Hi @DrewKimball, please add a branch-* label to identify the earliest affected branch for this C-bug

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