sql: prepare support for INSERT, UPDATE, DELETE

[maddyblue]

Make sure prepare statements are run in a transaction.

Use a new boolean flag on the planner to indicate prepare. Statement
implementations will gain knowledge of work to omit during prepare. An
alternative implementation would split up the prepare and exec portions of
the work. However, this would require passing around significant amounts
of state and I think the best implementation is the one here.

Keep a whitelist of statement types that support preparation instead of
attempting to exec them during prepare.

This also functions as a refactor for prepare statements in
general. Previously, we called parser.InferArgs, which walked the statement
and ran TypeCheck on all expressions. It turns out this is not needed,
since Select (and others) do this themselves. Thus, we can invoke those
worker functions directly but teach them about prepareOnly so they can
omit work once the val args have been populated and the type checks done.

Fixes #3819

[petermattis]

Sort of strange that these are test cases. They are really part of test setup. I think it would be cleaner to pull them out and actually perform them as separate setup steps. You can do something like:

  setup := `CREATE DATABASE d; CREATE TABLE d.t (i INT, s STRING, d INT);`
  if err := db.Exec(setup); err != nil {
    t.Fatal(err)
  }

[maddyblue]

Review status: 0 of 12 files reviewed at latest revision, 4 unresolved discussions.

---

sql/pgwire_test.go, line 330 [r1] (raw file):
Done.

---

sql/pgwire_test.go, line 396 [r1] (raw file):
Adding a TODO for this, discussed below.

---

sql/plan.go, line 171 [r1] (raw file):
Adding a TODO for that.

---

Comments from the review on Reviewable.io

[petermattis]

LGTM

---

Review status: 0 of 12 files reviewed at latest revision, 1 unresolved discussion.

---

Comments from the review on Reviewable.io