"standby switchover": force checkpoint if pg_rewind requested.

Addresses issue described in GitHub #378.

PostgreSQL itself doesn't issue a checkpoint after promotion to ensure
the newly promoted server is available as quickly as possible, so we'll
only execute an explicit CHECKPOINT when it's actually required, i.e.
when pg_rewind will be executed. This is required as pg_rewind uses
the timeline reported in the pg_control file to compare with the
server to be rewound, and the pg_control timeline is only updated after
the first checkpoint, so there is an interval where pg_rewind will
erroneously assume both servers are on the timeline and take no action.

repmgr-action-standby.c

@@ -3474,6 +3474,19 @@ x	 */
 	/* promote standby (local node) */
 	_do_standby_promote_internal(local_conn, config_file_options.data_directory);
 
+
+	/*
+	 * if pg_rewind is requested, issue a checkpoint immediately after promoting
+	 * the local node, as pg_rewind compares timelines on the basis of the value
+	 * in pg_control, which is written at the first checkpoint, which might not
+	 * occur immediately.
+	 */
+	if (runtime_options.force_rewind == true)
+	{
+		log_notice(_("issuing CHECKPOINT"));
+		checkpoint(local_conn);
+	}
+
 	/*
 	 * Execute `repmgr node rejoin` to create recovery.conf and start the
 	 * remote server. Additionally execute "pg_rewind", if required and