sql: require CASCADE to drop physical shard column of hash index

[ajwerner]

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

In 21.2 and prior, hash-sharded indexes (USING HASH) created a physical, STORED computed column. When we drop the index and find that no other index is using the column, we drop the column too. This can be surprising to users. Dropping a column is much more expensive than dropping an index; dropping a column requires a full rewrite of the table. Also, dropping a column can be disruptive to changefeeds (#35738).

Describe the solution you'd like

We should require CASCADE to drop an index which implies the drop of a shard column.

Describe alternatives you've considered
We could, additionally, provide some syntax to prevent the index from dropping the shard column. We could also just never drop the shard column. Perhaps one approach is to have a session variable to not drop the shard column and reference it in the error message when cascade is not provided.

Additional context

#77316 made dropping shard columns or adding them somewhat less painful for changefeeds, but until we remove the column backfill (#47989, hopefully in 22.2), dropping the column remains very painful because of #35738.

For hash indexes created in 22.1 and later, this issue isn't really relevant. Dropping a virtual computed column is no problem. Nevertheless, tables with physical shard columns can exist in later versions because of upgrades or restores.

Jira issue: CRDB-15819