sql: rollback of create table hits slow path for table deletion

[fqazi]

Describe the problem

Please describe the issue you observed, and any steps we can take to reproduce it:

When rolling back a create table AS operation, we can end up not populating the drop time within the table descriptor, which can lead to us using the wrong code path inside the GC job:

// If DropTime isn't set, assume this drop request is from a version
// 1.1 server and invoke legacy code that uses DeleteRange and range GC.
if table.GetDropTime() == 0 {
    log.Infof(ctx, "clearing data in chunks for table %d", table.GetID())
    return sql.ClearTableDataInChunks(ctx, db, codec, sv, table, false /* traceKV */)
}

This scenario can be easily hit by taking a CREATE TABLE AS operation and cancelling it in the middle, which will cause us to drop the table. When the GC job is created it will incorrectly end up using this slower code path, instead of clearing the entire range.

We should populate the drop time and completely remove the 1.1 legacy behaviour.

To Reproduce

What did you do? Describe in your own words.
Execute a large CREATE TABLE AS operation, and cancel it as we are backfilling the table.

Expected behavior
We should be able to quickly delete the data and drop the table, but end up using a slower code path because of backwards compatbility.

Additional data / screenshots
If the problem is SQL-related, include a copy of the SQL query and the schema
of the supporting tables.

If a node in your cluster encountered a fatal error, supply the contents of the
log directories (at minimum of the affected node(s), but preferably all nodes).

Note that log files can contain confidential information. Please continue
creating this issue, but contact support@cockroachlabs.com to submit the log
files in private.

Jira issue: CRDB-14585

[ajwerner]

Good find!