sql, jobs: schema change jobs are erroneously queued for in-txn schema changes

[thoszhang]

In cockroach demo on 2863173:

[email protected]:56758/movr> begin;
Now adding input for a multi-line SQL transaction client-side (smart_prompt enabled).
Press Enter two times to send the SQL text collected so far to the server, or Ctrl+C to cancel.
You can also use \show to display the statements entered so far.
                        -> create table t (a int);
                        -> alter table t add column b int;
                        -> commit;
COMMIT

Time: 27.151ms

[email protected]:56758/movr> show jobs;
        job_id       |   job_type    |                                                        description                                                         | statement | user_name |  status   | running_status |             created              |             started              |             finished             |             modified             | fraction_completed | error | coordinator_id
---------------------+---------------+----------------------------------------------------------------------------------------------------------------------------+-----------+-----------+-----------+----------------+----------------------------------+----------------------------------+----------------------------------+----------------------------------+--------------------+-------+-----------------
  536958125229670401 | SCHEMA CHANGE | ALTER TABLE movr.public.t ADD COLUMN b INT8                                                                                |           | root      | succeeded | NULL           | 2020-03-11 14:30:15.362633+00:00 | 2020-03-11 14:30:15.377983+00:00 | 2020-03-11 14:30:15.384583+00:00 | 2020-03-11 14:30:15.383424+00:00 |                  1 |       |              1
<...other rows...>

We shouldn't be queuing a job for new tables where schema changes are run entirely in the transaction in which the table was created. This is happening because we're calling runSchemaChangesInTxn() in planner.writeTableDescToBatch() if the table is new, but we always indiscriminately queue a schema change job before that. The job doesn't do anything because the schema change was finished, but we should still fix this and write a regression test for it.