* Change test cases for gpinistandby -F parameter.
* Fix get standby data directory by gp_segment_configuration instead of pg_filespace_entry
* Fix gpinitstandby to follow old behavior if option -d not given

Author: Xiaoran Wang <xiwang@pivotal.io>
Author: Max Yang <myang@pivotal.io>

A timeline history file would be generated to track timeline change,
and we copy the last wal file as wal file of current timeline. The split
point in history file would take care of correct recovery.

Author: Xiaoran Wang <xiwang@pivotal.io>
Author: Max Yang <myang@pivotal.io>

Make sure that recovery.conf file does not exist after promotion.
The file is renamed to recovery.done, like in upstream.

The previous patch failed, since we could not actually access the
catalog without some more initialization. Pull as much initialization
from the old Pass4 as possible -- some of it is likely not needed, but
this seems to get things working for now.

Author: Xin Zhang <xzhang@pivotal.io>
Author: Ashwin Agrawal <aagrawal@pivotal.io>

The failure was due to filespace removal. Fixed to use correct syntax.

Author: Xin Zhang <xzhang@pivotal.io>
Author: Ashwin Agrawal <aagrawal@pivotal.io>

If this works will remove all other pg_twophase make targets and jobs
from CI. As to run one test creating the full VM, is not efficient.

The previous check in gptransfer for matching source and destination filespaces
has been changed to a check for tablespaces, since filespaces no longer exist.

Also, gptransfer tests related to filespaces and the corresponding files have
been removed or altered accordingly.

Author: Jamie McAtamney <jmcatamney@pivotal.io>

Filespaces are no more.

CREATE/DROP TABLESPACE are not transactional, and are not recovered entirely
cleanly if a crash happens at the right moment. That's a known issue,
inherited from PostgreSQL, and we'll live with it.

I missed this one in the previous commit.

CREATE TABLESPACE isn't transactional. Rolling it back doesn't work
properly. This is a known limitation in PostgreSQL, we'll live with it.

* Disable tests with crash_type=failover_to_primary or failover_to_mirror.
  They were tightly-coupled with file replication. I'm not sure if we
  should have something to replace them...

* Disable tests with cluster_state=change_tracking or resync.
  These states don't exist anymore. I don't think we need a replacement
  for these.

CTAS isn't any different from a regular CREATE TABLE, as far as two-phase
commit is concerned. We don't need to test it separately.

We had allowed it in GPDB, when we had all the fancy persistent table
and filespace mechanisms to track the created-but-not-yet-committed
tablespace creation. The upstream mechanism is more crude, and can't
handle that gracefully. For example, if you abort the CREATE TABLESPACE
transaction, the directory structure would be left behind. Or worse,
when you DROP TABLESPACE, the underlying directory is deleted immediately,
even if the transaction aborts. Hence, put back the upstream limitation.
That's been acceptable for Postgres, and is surely acceptable for GPDB
as well.

Backport from PostgreSQL 9.0:

commit db64a9d20eeb0d3a52b7fb520a88bc68b73b374b
Author: Bruce Momjian <bruce@momjian.us>
Date:   Tue Jul 20 18:14:25 2010 +0000

    Properly replay CREATE TABLESPACE during crash recovery by deleting
    directory/symlink before creation.

    Report from Tom Lane.

    Backpatch to 9.0.

This change help `FtsTestConnection()` to correctly report segment
state. `probeWalRepPublishUpdate()` updating fts_status if
primary/mirror gets marked as down.

Also, removed all other states and code setting the same as its not
used for anything.

This is a far cry from actually making the tests work, but let's see what
the next error is after this is fixed.

As a followup to the removal of multipass logic in commit 813b817c:

* Make sure that recovery.conf file does not exist after promotion.
  The file is renamed to recovery.done, like in upstream.

* Update gp_segment_configuration after promotion only if we are a
  master's standby.

* We can't actually access the catalog without some more
  initialization. Pull as much initialization from the old Pass4 as
  possible -- some of it is likely not needed, but this seems to get
  things working for now.

Author: Asim R P <apraveen@pivotal.io>
Author: Jacob Champion <pchampion@pivotal.io>

Author: C.J. Jameson <cjameson@pivotal.io>

Speculative removals, as these tests were halfway through being ported
into Behave / unit tests. These tests are not actively run in a
pipeline; follow-up stories are being highlighted for upcoming work

Author: C.J. Jameson <cjameson@pivotal.io>

- Continuation of previous general filespace removal commits

Author: C.J. Jameson <cjameson@pivotal.io>

The server-side code to exclude the listed files was accidentally removed,
with the removal of filespace-related changes to basebackup.c. Resurrect
it.

Harmless, but compiler warnings are not nice.

The code used to wait for sent_location == replay_location, but that had
similar problems that we had with the similar code in gp_replica_check
earlier.

Firstly, there is no guarantee that a checkpoint had been sent to the
mirror, by the time that we check for it. So even if sent_location ==
replay_location, it was possible that the checkpoint hadn't even been sent
to the mirror. That was highly unlikely in practice, though.

Secondly, there are some corner cases where the primary would send half
of a WAL record, up to a page boundary, but not the rest of the record,
until something nudges it. I think that happens if the WAL record is
not part of a transaction, so that there is no commit record to force it
to be flushed. In that case, replay_location would not catch up to
sent_location, because sent_location would point in the middle of a WAL
record, and the standby can't replay half of a WAL record. That situation
would persist until there's some new WAL activity to force it to be flushed,
which could take longer than the timeout used in the test (possibly
forever).

To fix, memorize the WAL posititions on each segment, after issuing the
CHECKPOINT, and wait until replay_location catches up to that position.
That more accurately reflects what we are trying to accomplish: we want
to wait until the checkpoint has been replayed, not necessarily that the
standby is completely in sync with the primary. (gp_replica_check needed
more strict logic, it wants the standby to really catch up to the primary,
not just up to the latest checkpoint.)

This hopefully fixes the occasional failures of the missing_xlog test we've
been seeing in the pipeline.

Include the diff between the first mismatching byte in the log output
as we have it, and it can aid debugging (it just now helped me). Can't
hurt.

Commit f4c05df21d0906482e38010b15bac8221f52ee0b temporarily removed
sequences from gp_replica_check due to them causing failures. Re-add
them again as the masking should be fixed now.

SEQ_LOG_VALS are pre-logged to avoid logging every fetch from a
sequence, so we need to mask out last_value and log_cnt for sequence
pages before running consistency checks.

Makes filenames in mismatch messages consistently quoted and
includes the length diff for ease of debugging.