sql: bugfixes around writing the old primary key in pk changes

[rohany]

This PR fixes two bugs:

• The logic for when to rewrite the old primary key was broken
  resulting in the old primary key not being rewritten in many cases.
• The old primary key being created was not properly dealing with
  its dangling interleave information.

This PR makes the design decision to not re-interleave the copy of the old primary index if it was interleaved.

Release note: None

[cockroach-teamcity]

This change is 

[solongordon]

Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @rohany and @solongordon)

---

pkg/sql/alter_table.go, line 402 at r1 (raw file):

			// TODO (rohany): is there an easier way of checking if the existing primary index was the
			//  automatically created one?
			if !(len(n.tableDesc.PrimaryIndex.ColumnNames) == 1 && n.tableDesc.PrimaryIndex.ColumnNames[0] == "rowid") {

Not ideal that this would also apply to a user who happened to create a table with a primary key called "rowid". Could you look for a more reliable way to detect this? Maybe also check that rowid is a hidden column?

---

pkg/sql/alter_table.go, line 407 at r1 (raw file):

					"old_primary_key",
					nameExists,
				)

This can be addressed in a separate PR, but I don't love the "old_primary_key" name. What if we just named it the same way we name other indexes where the user doesn't specify a name? Like if you add INDEX (x, y) on a table named t, we call the index t_x_y_idx.

[rohany]

PTAL

[solongordon]

Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @rohany and @solongordon)

[rohany]

bors r+

[craig]

Build failed (retrying...)

• GitHub CI (Cockroach)

[craig]

Build succeeded

• GitHub CI (Cockroach)