Split existing tests into two files

About to add a ton more unit tests, so to avoid having a few thousand
lines in a single file we'll separate these by concern.
Add more unit tests for distribution metadata

Since we last wrote metadata tests, we've added caching, locking, and
modification (INSERT/DELETE) functions. Now all are tested.
Add DDL generation unit tests

Independently tests DDL generation functionality by creating many small
tables exercising various SQL features and asking for DDL statements to
recreate them.

Also tests functionality to generate a list of foreign table OPTIONS,
which is used to recreate foreign tables.
Add DDL extension unit tests

These tests feed an SQL statement and shard identifier into our DDL
extension functions to verify that shard identifiers are added to the
appropriate locations within DDL commands (index, constraint, and table
identifiers, mostly).
Add unit tests for shard creation

This required a special approach. Because the default behavior of PGXS-
based extensions is to use the installcheck target (which tests against
an existing PostgreSQL installation), we cannot assume anything about
the user's cluster. But we don't want to clobber their config, either.

So what to do? pg_regress has an option to use a launcher script rather
than calling psql directly. I've added one which:

  1. Moves the worker list configuration out of the way
  2. Replaces it with a known configuration
  3. Runs tests
  4. Moves the original configuration back into place

This is tedious, but works well to exercise all branches without any
knowledge of the user's cluster configuration.

Adding such a launcher allows us to test the shard creation logic,
which—while still modular—is the first end-to-end test thus far: we
actually build tables for shards and insert metadata to reflect this.
Add unit tests for shard pruning

Populates the metadata table with a bunch of shards and runs through a
couple of pruning scenarios.
Add shard repair unit tests; fix bad strncmp use

This test builds a shard, puts some data in it, marks it as unhealthy,
and runs the repair command on its placement. We verify that the shard
has been rebuilt by comparing its OID with the OID of the pre-repair
relation.

A little hacky, but it's the best we can do without more scaffolding.
Add modification integration tests

Extensive tests for INSERT, DELETE, and UPDATE commands. Both "happy
path" and failure (or unsupported) cases are tested. This is an actual
integration test: we're looking at the end-to-end system, not a module.
Add query integration tests

Extensive tests for both single- and multi-shard SELECT queries. Again,
we try to cover all cases, both supported and not. Wraps up initial
integration testing as far as supported features go.
Add utility integration tests

These are all unsupported features, but we have code to prevent users
from doing undesirable things, so here are the tests.
Document test functions

A little pedantic to do so, but whatever.