schemachanger: check explain diagrams during rollback test

[postamar]

This commit enriches the declarative schema changer integration tests by
making data-driven EXPLAIN output assertions easier to add as
a complement to otherwise unrelated tests. In particular, this commit
improves the rollback test to check the explained rollback plan for each
post-commit revertible stage. This should make it easier to debug bad
rule definitions which otherwise would manifest themselves as causing
the schema change to hang during the rollback.

Release note: None

[cockroach-teamcity]

This change is 

[postamar]

I was trying to rewrite some rules and struggled to debug them without any clear idea of what the expected plan was at rollback time. We also need more testing hooks inside the rollback test to catch planning errors like circular graphs etc but that's out of scope for this already considerable change (in terms of test artifacts at least).

[postamar]

This is ready for review. CI failures seem to be unrelated flakes.

[ajwerner]

I had hoped for this as an outcome after we made it one directive per test. Thanks for making it happen.

Reviewed 4 of 183 files at r1, all commit messages.
Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @ajwerner and @postamar)

---

pkg/sql/schemachanger/sctest/end_to_end.go line 206 at r1 (raw file):

		_, err := file.Write(prefixBuf.Bytes())
		require.NoError(t, err)
		_, err = fmt.Fprintf(file, "EXPLAIN (%s) %s;\n----\n", tag, explainedStmt)

Something rubs me the wrong way about using SQL syntax in EXPLAIN (ddl, verbose) rollback at post-commit stage 1 of 7; but not enough to block this strictly positive PR. I think I'd prefer if this was somehow a SQL-level comment, but I don't care that much.

[postamar]

Thanks for the review!

Something rubs me the wrong way about using SQL syntax in EXPLAIN (ddl, verbose) rollback at post-commit stage 1 of 7; but not enough to block this strictly positive PR. I think I'd prefer if this was somehow a SQL-level comment, but I don't care that much.

I know, right? I don't like it either. I'm left with the feeling we're lacking some jobs abstractions here, something to trigger a job failure when a particular condition is met. A bit like pausepoints; "failpoints" perhaps?

[postamar]

bors r+

[craig]

Build succeeded:

• GitHub CI (Cockroach)