Mode VoltDB 8.4.11 - Disable memory checking

Gets rid of the following message (as well as any performance penalties we may be paying):

WARN: Strict java memory checking is enabled, don't do release builds or performance runs with this enabled. Invoke "ant clean" and "ant -Djmemcheck=NO_MEMCHECK" to disable.

Mode VoltDB 8.4.11 - Merge upstream VoltDB to 8.4.11

Catches Mode VoltDB up to mainline VoltDB 8.4.11. This release also takes this opportunity to create a new branch (mode-release-8.4.x). The new name allows the Mode VoltDB branch name to follow the same branch naming pattern as the upstream repository. Additionally, rebasing Mode's changes fixes a previously mis-applied merge, which led to some SQL errors.

Cap PERCENTILE_N/MEDIAN methods at 1M rows per partition

Implements a 1M row cap on PERCENTILE_N/MEDIAN methods as a safeguard against runaway memory usage.

Without this check it's possible that the dist nodes on each partition could put an effectively infinite number of doubles into the underlying STL vector, opening the door for memory exhaustion.

The large table test has been updated to fill each of the available partitions up with 1M rows, test that the functions work properly, and then add 1 more row and make sure that the function aborts as expected.

Mode VoltDB 8.4.8 - Implement Naive PERCENTILE_N

Incorporates #12, implementing naive percentile methods (PERCENTILE_1, PERCENTILE_5, PERCENTILE_25, MEDIAN, PERCENTILE_75, PERCENTILE_95, and PERCENTILE_99).

The naive implementation is good for up to ~1M rows per partition, beyond which failures should be expected due to VoltDB VARBINARY size limits.

Mode VoltDB 8.4.8 - Fix ENG-18549

Incorporates #7, fixing a SQL parameterization bug in VoltDB (ENG-18549).

Mode VoltDB 8.4.8 - Fix ENG-18917

Incorporates #4, fixing a SQL parameterization bug in VoltDB (ENG-18917).

Mode VoltDB 8.4.6 - Compact Count Distinct

Incorporates #1 into the stock VoltDB 8.4.6, adding support for a new COMPACT_COUNT_DISTINCT SQL function, which is faster and more efficient than SELECT COUNT(DISTINCT column_name) FROM table_name while being more accurate than SELECT APPROX_COUNT_DISTINCT(column_name) FROM table_name.

Faster DDL execution time

Incorporates several optimizations to DDL execution time (see changes).