spanconfig: de-dup configs in system.span_configurations

[irfansharif]

Is your feature request related to a problem? Please describe.

We currently store the full config protobuf for each index in system.span_configurations. The unique set of configs you'd generally expect is going to an order of magnitude smaller than the number of tables/indexes. Storing a single copy of unique configs would likely save a lot of space for this system table and possibly speed up a class of operations around the table.

> show create table system.span_configurations;
             table_name             |                    create_statement
------------------------------------+----------------------------------------------------------
  system.public.span_configurations | CREATE TABLE public.span_configurations (
                                    |     start_key BYTES NOT NULL,
                                    |     end_key BYTES NOT NULL,
                                    |     config BYTES NOT NULL,
                                    |     CONSTRAINT "primary" PRIMARY KEY (start_key ASC),
                                    |     CONSTRAINT check_bounds CHECK (start_key < end_key)
                                    | )

Additional context

We use a similar optimization in the in-memory data structures constructed off this table state: 3b0df85. This de-duping was also left as future work in the original RFC. This might raise in importance as we continue adding more fields to span configs: #70614.

+cc @cockroachdb/sql-schema.

Jira issue: CRDB-16198

[ajwerner]

This seems unimportant in that it is unlikely that the total span config size is larger than the descriptors. Until the size of this table turns out to be a problem, this is going to a backlog.