sql: repair corruption due to DROP SCHEMA bug

[ajwerner]

Describe the problem

In #63119 we uncovered a typo bug that then causes corruption when you have schemas of the same name as the database. Fortunately we can repair this type of corruption pretty trivially. We should do this as a read-time repair and then we should write a long-running migration.

[postamar]

I could trigger this corruption by checking out v20.2.7, starting an empty cluster and running the following twice:

CREATE DATABASE foo;
USE foo;
CREATE SCHEMA bar;
DROP SCHEMA bar;

At this point the descriptor for foo is corrupted:

[email protected]:61368/foo> SELECT crdb_internal.pb_to_json('cockroach.sql.sqlbase.Descriptor', descriptor, false)->'database'->'schemas' FROM system.descriptor WHERE id >= 52;
                ?column?
----------------------------------------
  {"foo": {"dropped": true, "id": 52}}
(1 row)

The schemas map of the database descriptor should contain a bar field but instead it contains foo. Also note that the descriptor ID is that of foo. This is caused by the bug which uses the database name and ID by mistake to populate this map.

There are clusters out there right now with corrupted database descriptors. The impact is minor enough that we haven't heard about it but this should be repaired:

1. as a new step in RunPostDeserializationChanges.
2. as a long-running migration that operates on all database descriptors.

The reason that (2) is not enough on its own is that corrupted database descriptors may be present in backups, which can be restored after the migration has run (it runs only once during cluster upgrade).