Add support for GTM to backup data at BARRIER command

This patch is a combination of series of patches that were checked in the
upstream XC code
Disable hot_standby for components setup by pgxc_ctl

XL does not support Hot Standby, but hot_standby is set to "on" while
initializing datanode/coordinator slaves using pgxc_ctl. Fix that so that Hot
Standby is disabled by default
Disable internal subtransactions.
Allow DMLs inside a plpgsql procedure on the coordinator.

We still block them on the datanodes, but its safe to execute them on a
coordinator.
Fix planner bug with nested PlaceHolderVars in 9.2 (only).

Commit 9e7e29c75ad441450f9b8287bd51c13521641e3b fixed some problems with
LATERAL references in PlaceHolderVars, one of which was that "createplan.c
wasn't handling nested PlaceHolderVars properly".  I failed to see that
this problem might occur in older versions as well; but it can, as
demonstrated in bug #10587 from Geoff Speicher.  In this case the nesting
occurs due to push-down of PlaceHolderVar expressions into a parameterized
path.  So, back-patch the relevant changes from 9e7e29c75ad4 into 9.2 where
parameterized paths were introduced.  (Perhaps I'm still being too myopic,
but I'm hesitant to change older branches without some evidence that the
case can occur there.)

Conflicts:
	src/backend/nodes/equalfuncs.c
Add missing gtm backup files to the repo

We missed them in commit f70597bb
When fetching from remote nodes, after obtaining initial
group of rows, send down to the node that it should start producing
the next batch so it is ready when we are ready to read them.

Patch submitted by Jason
Send down command ID to datanodes before sending a plan.

Plans are sent down to the datanodes in form of a string and datanodes
convert them back to a RemoteStmt structure using stringToNode() function. Plan
string have relation names which must be converted back to their local OIDs.
For that, datanodes lookup system catalogs. Now if a table is created and later
accessed in the same transaction, and if access requires secondary datanode
connections from oher datanodes, then SnapshotNow fails to find that table.
This happens because command ID is not sent down to the datanode prior to the
plan string. So datanodes use FirstCommandId to do the scan and fails to see
the tuple inserted by the same transaction, but through a diff session.

Fix this my sending down command ID prior to plan. Bug report by Aaron
Jackson and investigation/fix from me.
Ensure that updated command ID is sent to the datanode once its updated in the
active snapshot on the coordinator/datanode

We have an optimization to discourage sending command ID unless its needed.
That works by tracking top level statements, but that not work when multiple
statements are executed as part of a single query. This can happen in
multi-portals or with plpgsql functions. So now we signal the coordinator (or
datanode in case of datanode-datanode communication) to send down updated
command ID when its updated in the active snapshot. More testing required to
ensure that there are no other paths which may require similar treatment.

Bug report and test case from Aaron Jackson. Fix by me.
Set the size of pending connections on a pooler socket to some respectable high
limit

The current count of 5 was showing up in errors while running pgbench tests
with more than 10 clients. This probably may not be a problem on all platforms
since some platforms have built-in ability to retry from the client side. But
it was definitely showing up on OSX
Refactor the XID assignment code.

The current code had become quite messy and error-prone. So that has been
refactored. We now make some simple assumptions to allow a gloabl XID to be
fetched from the GTM directly or use of local XIDs. Tha latter is restricted
only for initdb while former is useful for autovacuum launcher/worker, backend
initializing and certain commands such as VACUUM/CLUSTER which can't be run
inside a transaction block
Send down comamnd ID even before an utility statement is sent

We have seen corner cases where an utility statement on a datanode will
increment local command ID counter (say, because of cascade drop), but the same
is conveyed back to the remote coordinator. Later when coordinator sends down a
lower numbered command ID, catalog access fails to see an object created in the
same transaction.

This fixes the case reported by Aaron Jackson. But we would do further
refactoring on the command ID management to ensure all corner cases are handled
properly.
Merge pull request #5 from arcivanov/release_9.2.beta-20141205.0

Release 9.2.beta 20141205.0