In 3be31490 we changed max spill_ratio
to INT_MAX, but it will not take effect until more related logic is
accordingly changed.

Before we have all the work done we will change the max spill_ratio back
to 100.

User query can use global shared memory across resource group when available(Same as the PR 4843, just made the test cases stable) (#4866)

1) Global shared memory will be used if the query has run out of
	the group shared memory.
2) The limit of memory_spill_ratio changes to [0, INT_MAX], because
	global shared memory can be allocated, 100% limitation is not
	make sense.
3) Using Atomic Operation & "Compare And Save" instead of lock to
	get high performance.
4) Modify the test cases according to the new rules.

Revert "User query can use global shared memory across resource group when available(#4843)" (#4862)

This reverts commit a5b3831d.

1) Global shared memory will be used if the query has run out of
	the group shared memory.
2) The limit of memory_spill_ratio changes to [0, INT_MAX], because
	global shared memory can be allocated, 100% limitation is not
	make sense.
3) Using Atomic Operation & "Compare And Save" instead of lock to
	get high performance.
4) Modify the test cases according to the new rules.

By default the memory management in resource group is
implemented by tracking every memory alloc/free in memory
context.

To support external components ( such as plcontainer) which
do not use memory context, cgroup memory auditor is added
into resource group.

Note that catalog table pg_resgroup is changed.

Allow CREATE RESOURCE GROUP and ALTER RESOURCE GROUP to set concurrency
to 0, so there will eventually be no running queries after some time, so
the resource group can be dropped. On drop all pending queries will be
moved to the new resource group assigned to the role; but if the role is
also dropped the pending queries will all be canceled. Another thing is
we do not allow setting concurrency of admin group to zero, superuser is
under admin group and only superuser can alter resource group, so once
concurrency of admin group is set to zero, there will be no chance to set
it again.
Signed-off-by: NNing Yu <nyu@pivotal.io>

This commit does two changes:
1. Remove the restriction that sum of memory_spill_ratio and memory_shared_quota
must be no larger than 100.
2. Change the range of memory_spill_ratio to be [0, 100].

Now we support the resgroup memory_limit memory_shared_quota alteration
in below syntax:

	ALTER RESOURCE GROUP <group> SET MEMORY_SHARED_QUOTA <value>;
	ALTER RESOURCE GROUP <group> SET MEMORY_LIMIT <value>;

The new value may take effect immediately if the actual shared memory
usage is lower than the new value; otherwise it will delay the effect.
Signed-off-by: NHaisheng Yuan <hyuan@pivotal.io>

resource group tests are messing up isolation2 directory, this commits
move them all to the same directory to be tidy and organized, it also
handle the sub directory in input/output directory for resgroup.

Change initial contents in pg_resgroupcapability:
* Remove memory_redzone_limit;
* Add memory_shared_quota, memory_spill_ratio;

Change resgroup concurrency range to [1, 'max_connections']:
* Original range is [0, 'max_connections'], and -1 means unlimited.
* Now the range is [1, 'max_connections'], and -1 is not supported.

Change resgroup limit type from float to int.

Changed below resgroup resource limit types from float to int percentage value:
* cpu_rate_limit;
* memory_limit;
* memory_shared_quota;
* memory_spill_ratio;

Implement resgroup memory limit.

In a resgroup we divide the memory into several slots, the number
depends on the concurrency setting in the resgroup. Each slot has a
reserved quota of memory, all the slots also share some shared memory
which can be acquired preemptively.

Some GUCs and resgroup options are defined to adjust the exact allocation
policy:

resgroup options:
- memory_shared_quota
- memory_spill_ratio

GUCs:
- gp_resource_group_memory_limit
Signed-off-by: NNing Yu <nyu@pivotal.io>

Support ALTER RESOURCE GROUP SET CPU_RATE_LIMIT syntax.

The new cpu rate limit take effect immediately at end of transaction.

Example 1:

    CREATE RESOURCE GROUP g1
        WITH (cpu_rate_limit=0.1,memory_limit=0.1);
    ALTER RESOURCE GROUP g1 SET CPU_RATE_LIMIT 0.2;

The new cpu rate limit take effect immediately.

Example 2:

    BEGIN;
    ALTER RESOURCE GROUP g1 SET CPU_RATE_LIMIT 0.2;

The new cpu rate limit doesn't take effect unless the transaction is
committed.
Signed-off-by: NRichard Guo <riguo@pivotal.io>
Signed-off-by: NGang Xiong <gxiong@pivotal.io>

A dedicated list is maintained for resource group related callbacks.
At transaction end, the callback functions are processed in the order
of FIFO on COMMIT, and in the order of LIFO on ABORT.
Signed-off-by: NPengzhou Tang <ptang@pivotal.io>

As cgroup is now required to enable resgroup on linux and cgroup itself
requires privileged permission to setup & config, so resgroup tests will
fail or at least produce extra warnings in ICW pipeline. We moved them
to the installcheck-resgroup target as there is a standalone privileged
pipeline to run this target.

Also the tests are updated as the psql output format is different
between ICW and installcheck-resgroup.

Increase the 'concurrency' limit can take effect immediately, and the
queueing transactions can be woken up. Decrease the 'concurrency' is
different, if the new limit is smaller than the number of current running
transactions, ALTER statement won't cancel the running transactions to
the limit. Therefore, we use column 'proposed' in pg_resgroupcapability
to represent the effective limit, and use column 'value' to record the
historical limit.
For example, we have a resource group with concurrency=3, and there
are 3 running transactions and 3 queueing transactions. If we alter the
concurrency to 2, 'proposed' will be updated to 2 and 'value' will stay
as 3. When one running transaction is finished, it won't wake up the
transactions in the queue as the current concurrency is 2. If we execute
the statement again to alter the concurrency to 2, it will update the
'value' column to 2, and the 'value' is consistent with 'proposed'
again.
Signed-off-by: NRichard Guo <riguo@pivotal.io>

Any resgroups created by CREATE RESOURCE GROUP syntax can be dropped
with DROP RESOURCE GROUP syntax; the default resgroups, default_group
and admin_group, can't be dropped; only superuser can drop resgroups;
resgroups with roles bound to can't be dropped.

    -- drop a resource group
    DROP RESOURCE GROUP rg1;

*NOTE*: this commit only implement the DROP RESOURCE GROUP syntax, the
actual resource management are not yet supported, which will be provided
later based on these syntax commits.

*NOTE*: test cases are provided for both CREATE and DROP syntax.
Signed-off-by: NPengzhou Tang <ptang@pivotal.io>

There is the same restrictions with the CREATE ROLE syntax, only
superuser can be assigned to the admin_group.

    -- assign the role r1 to resource group g1
    ALTER ROLE r1 RESOURCE GROUP g1;
Signed-off-by: NNing Yu <nyu@pivotal.io>

There are two default resource groups, default_group and admin_group,
roles will be assigned to one of them depending on they are superuser or
not unless a group is explicitly specified. Only superuser can be
assigned to the admin_group.

    -- create a role r1 and assign it to resgroup g1
    CREATE ROLE r1 RESOURCE GROUP g1;
Signed-off-by: NNing Yu <nyu@pivotal.io>