This fixes the test failure introduced in commit effc38f6

fixes #809
[delivers #120723853]

This commit generates code for a naive code-generated version of ExecQual that simply fallbacks to regular ExecQual.
The code-generated ExecQual is enrolled in the existing codegen framework and is called only in ExecScan.
After the implementation of the function (i.e., generate code for expression evaluation), we can replace all calls to regular ExecQual with call_ExecQual macros.

 * Address a number of cpplint errors
 * Fix files and variable naming for ExecVariableList codegen
 * Ignore Testing directory created by ctest

The 8.3 merge added a new opr_sanity test that caught that. But it's
been broken all along, so fix it now. We'll get the regression test later,
with the merge.

Backport this bugfix from PostgreSQL 9.0, because we had backported
src/timezone or at least localtime.c from 9.0. This brings localtime.c
in sync with the tip of REL9_0_STABLE. (PostgreSQL 9.0 is end-of-life
already, so there won't be any more fixes in that branch in the upstream.)

commit 6b87144323fe4cf920ea4d095cce93a84c9b8922
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date:   Wed Apr 25 17:25:30 2012 -0400

    Fix edge-case behavior of pg_next_dst_boundary().

    Due to rather sloppy thinking (on my part, I'm afraid) about the
    appropriate behavior for boundary conditions, pg_next_dst_boundary() gave
    undefined, platform-dependent results when the input time is exactly the
    last recorded DST transition time for the specified time zone, as a result
    of fetching values one past the end of its data arrays.

    Change its specification to be that it always finds the next DST boundary
    *after* the input time, and adjust code to match that.  The sole existing
    caller, DetermineTimeZoneOffset, doesn't actually care about this
    distinction, since it always uses a probe time earlier than the instant
    that it does care about.  So it seemed best to me to change the API to make
    the result=1 and result=0 cases more consistent, specifically to ensure
    that the "before" outputs always describe the state at the given time,
    rather than hacking the code to obey the previous API comment exactly.

    Per bug #6605 from Sergey Burladyan.  Back-patch to all supported versions.

This was useful while debugging on the 8.3 merge branch. It might come
handy in the future too, and it's cheap.

The convenience routine isn't really all that convenient. Aside from
refactoring, this turns the NULL checks from an Assert to elog(). Seems more
robust. (I happened to hit the assertion, while hacking on something else.)

This was done in the upstream earlier already, in commit 8b4ff8b6, but there
were a few GPDB-added error messages left. Fix those too, for consistency.

This is inside an if-check that checks the same. Plus some whitespace fixes.
Caught my eye while debugging..

There's no need to be able to read nodes generated by an old version. We're
not going to handle upgrades that way.

Not strictly necessary, but couldn't resist..

The VERBOSE option was always ignored, so this is no loss in functionality,
you just can't add that noiseword there anymore. According to git history,
this was added to the syntax back in 2009, for "PostgreSQL compatibility",
but AFAICS PostgreSQL has never had VERBOSE option for CLUSTER, so I have
no idea what that was all about. It's possibly worth noting in release
notes as a backwards-incompatibility, though.

Having a "checkpoint.h", corresponding to "checkpoint.c", makes perfect
sense, but those function definitions are in bgwriter.h in PostgreSQL, and
keeping the code as close to upstream as possible trumps the consistency of
keeping definitions for "foo.c" in header file called "foo.h". Keeping
things close to upstream makes merging easier.

These created merge conflicts while working on the 8.3 merge. In order to
keep that upcoming big merge slightly smaller, cherry-pick this change to
master now. pg_depend.c was already completely identical to the PostgreSQL
8.3 version, except for the use of CaQL.

Well, almost: there was also one instance of changing an old
heap_formtuple() call to the new heap_form_tuple() interface. I kept that
change. But other than that, the file is now 100% identical to upstream.

We don't particularly care about performance on Solaris at the moment, and
have no Solaris systems to test on. Let's just rely on the upstream
defaults, and revert this change to reduce our diff footprint vs. upstream.

If a page has hint bits set, but the buffer has not been marked as dirty,
and it gets evicted between the 1st and 2nd vacuum pass, the 2nd pass
gets upset. That can't happen in the upstream, as setting a hint bit
always marks the buffer as dirty, but that is not guaranteed in GPDB, because
of gp_disable_tuple_hints.

Includes tests:
  composite_keys_gpdb_1
  composite_keys_gpdb_3
  composite_keys_gpdb_2
  partitionindexes
  staticselection
  cte_functest
  cte_queries
  create_table_default_distribution
  lastj lastj_hash
  indexapply

Commit 33a1278c merged upstream addition of a typmod argument to
makeConst(). However, one of the calls was botched during the merge, and
the typmod argument was inserted to wrong place in argument list. This
seems to have been harmless because the constant ended up being NULL
anyway, and the bogus values for the other arguments were ignored.

These got in the way in the PostgreSQL 8.3 merge, so let's get them over
with before the big merge lands.

This makes no difference at runtime, as the argument is always passed as
NULL anyway, but let's avoid unnecessary differences vs. upstream.

These changes were lifted from upcoming PostgreSQL 8.3 merge branch, but
are not related to the merge per se, so let's get them out of the way
before the big merge lands. Plus other cosmetic things in neighbouring
code that stuck my eye.

A new regression test was added in the upstream that does work_mem='64kB',
which used to fail without --enable-cassert. There's little reason to not
allow a small value here, so let's just allow it. It doesn't mean that
anyone should use such a small value in production, but that's just a
matter of "don't do that then".

The minimum was changed later in the upstream, too, to be 64 kb regardless
of BLCKSZ.

prev_item variable needs to be reset between the two loops. Otherwise,
if the first item in the latter list (allocatedReaderGangs1) needs to
be removed, things go wrong. I got an assertion failure with
installcheck-good from that:

FailedAssertion(""!(prev != ((void *)0) ? ((prev)->next) == cell : list_head(list) == cell)"", File: ""list.c"", Line: 616)

This got broken in the recent refactoring commit 46dfa750. The rest of the
changes in this commit, introducing the new next_item variable, wasn't
needed for correctness, but IMHO makes the code easier to understand.

I missed this in commit af7b1b51, which reverted the backend shutdown code
closer to the upstream. Without it, auxiliary proc slots are never reused,
so you run out of them fairly quickly, if any (non-permanent) auxiliary
processes are used.

Reported by Gang Xiong, who ran into this with gprecoverseg.

The checks for invalid TIDs are very cheap, a few CPU instructions. It's
better to catch bugs involving invalid TID early, so let's always check
for them.

The LOGs in storeAttrDefault() that were also tied to this GUC seemed
oddly specific. They were probably added long time ago to hunt for some
particular bug, and don't seem generally useful, so I just removed them.

Previously, the functions and subclasses in gpcrondump, gpdbrestore, dump.py,
and restore.py all required long lists of arguments to be passed around and
required many helper functions.  This made adding new command-line options
or new features quite time-consuming to implement and to test.

Now, a Context class has been added to backup_utils.py that holds all of the
variables used for command-line options, as well as other variables used in
many places during backup and restore; additionally, many helper functions
have been condensed into a few functions within Context, and in the future
more such functions can be moved to Context as needed.  This will make it
much easier to expand dump and restore functionality going forward.

This way we can reuse the csv files in other installcheck suites.

Caught by access_methods/indexscan TINC tests.

This seems like a copy-paste error since the IDENTIFICATION marker
is a PostgreSQL artifact and Peter Eisentraut probably didn't write
the gpopt Makefile. Remove to make it look like the headers in other
GPDB specific makefiles.