pgsql: Fix array- and path-creating functions to ensure padding bytes a

Fix array- and path-creating functions to ensure padding bytes are zeroes.

Per recent discussion, it's important for all computed datums (not only the
results of input functions) to not contain any ill-defined (uninitialized)
bits. Failing to ensure that can result in equal() reporting that
semantically indistinguishable Consts are not equal, which in turn leads to
bizarre and undesirable planner behavior, such as in a recent example from
David Johnston. We might eventually try to fix this in a general manner by
allowing datatypes to define identity-testing functions, but for now the
path of least resistance is to expect datatypes to force all unused bits
into consistent states.

Per some testing by Noah Misch, array and path functions seem to be the
only ones presenting risks at the moment, so I looked through all the
functions in adt/array*.c and geo_ops.c and fixed them as necessary. In
the array functions, the easiest/safest fix is to allocate result arrays
with palloc0 instead of palloc. Possibly in future someone will want to
look into whether we can just zero the padding bytes, but that looks too
complex for a back-patchable fix. In the path functions, we already had a
precedent in path_in for just zeroing the one known pad field, so duplicate
that code as needed.

Back-patch to all supported branches.

Branch
------
REL8_4_STABLE

Details
-------
http://git.postgresql.org/pg/commitdiff/4dcc4fd28818fef0edc90bbdb65b7a85de6963e2

Modified Files
--------------
src/backend/utils/adt/array_userfuncs.c | 2 +-
src/backend/utils/adt/arrayfuncs.c | 14 +++++++-------
src/backend/utils/adt/geo_ops.c | 6 ++++++
3 files changed, 14 insertions(+), 8 deletions(-)