pgsql: Rework activation of commit timestamps during recovery

Rework activation of commit timestamps during recovery

The activation and deactivation of commit timestamp tracking has not
been handled consistently for a primary or standbys at recovery. The
facility can be activated at three different moments of recovery:
- The beginning, where a primary would use the GUC value for the
decision-making, and where a standby relies on the contents of the
control file.
- When replaying a XLOG_PARAMETER_CHANGE record at redo.
- The end, where both primary and standby rely on the GUC value.

Using the GUC value for a primary at the beginning of recovery causes
problems with commit timestamp access when doing crash recovery.
Particularly, when replaying transaction commits, it could be possible
that an attempt to read commit timestamps is done for a transaction
which committed at a moment when track_commit_timestamp was disabled.

A test case is added to reproduce the failure. The test works down to
v11 as it takes advantage of transaction commits within procedures.

Reported-by: Hailong Li
Author: Masahiko Sawasa, Michael Paquier
Reviewed-by: Kyotaro Horiguchi
Discussion: https://postgr.es/m/11224478-a782-203b-1f17-e4797b39bdf0@qunar.com
Backpatch-through: 9.5, where commit timestamps have been introduced.

Branch
------
REL9_6_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/e513a3d854a13c141e7d73e209ad44d789352479

Modified Files
--------------
src/backend/access/transam/commit_ts.c | 9 ++++-----
src/backend/access/transam/xlog.c | 9 +++++----
2 files changed, 9 insertions(+), 9 deletions(-)