Introduce query limits at the resource group level

[kyleCampbel1]

Introduce the ability to add query limits (cpu time, execution time, and memory limit) at the resource group level. These limits can complement the SelectorResourceEstimate passed to SelectorSpec to ensure that if the query exceeds the indented query limits, we can fail the query and protect the resource group.

This is enabled by adding to the ResourceGroupSpec the field perQueryLimits, a JSON object of the optional fields executionTimeLimit, totalMemoryLimit, cpuTimeLimit which is then passed to the coordinator to implement the appropriate limits.

Test plan - Unit tests added and build success are sufficient for first commit. Second commit will have e2e by deploying fbpkg to test cluster to ensure resource group limits can be enforced by SqlQueryManager. Unit testing also on second commit.

Depends on https://github.com/facebookexternal/presto-facebook/pull/1599

== RELEASE NOTES ==

Resource Groups Changes
* Add support to specify query limits (Cpu time, total memory and execution time) at the resource group level. See :doc:`/admin/resource-groups`.

SPI Changes
* Add `ResourceGroupQueryLimits` to the SPI and the corresponding getter and setter functions in `ResourceGroups`.

[mayankgarg1990]

At a high level - 2 main comments here -

1. Lets rename the field names to start with perQuery and end with Limit. If the variable type is DataSize/Duration - then the name can end with Limit. However, if the fields have the type long - in that case we need to put the unit at the end of the name likes Millis or Bytes so that it is clear to the reader of the code what is the unit in question for the long value.
2. Use requireNonNull wherever possible in constructors to ensure that we are not passing around nulls

[mayankgarg1990]

One thing I realized after reviewing this PR is that the values that we passed to InternalResourceGroup is not really being used since we are just using the values from ResourceGroupConfigurationManager - lets see if we need those changes - we can make the changes a lot simpler

[mayankgarg1990]

haven't reviewed the full PR - will continue the same tomorrow

[mayankgarg1990]

Review for commit " Add resource limits per query on a resource group "

[mayankgarg1990]

flushing some more comments

[mayankgarg1990]

Add resource limits per query on a resource group

For this commit - mostly good - just some naming issues

You should rename the commit title to Support passing per query limits in resource group configuration

The commit description starts with saying Allows for more intelligent thread allocation for queues - this diff commit doesn't do that. Please ensure that the commit description and title matches with what the commit actually does

[mayankgarg1990]

Also - please make the SelectorResult/SelectionContext changes we talked about

[mayankgarg1990]

@tdcmeehan - this diff is ready for an initial look. We are still looking at unittests and code style fixes - but otherwise - would love to get an idea on the approach and the PR should be ready for final review by tomorrow.

[mayankgarg1990]

Getting there - this should be last major set of review comments

[mayankgarg1990]

Commit 1

[mayankgarg1990]

mostly naming changes and things here and there

[mayankgarg1990]

LGTM !

[arunthirupathi]

testTwoQueriesAtSameTime is failing most of the times. I have several open PRs and i have seen that failing at least 3 times.

https://github.com/prestodb/presto/pull/16434/checks?check_run_id=3128611696#step:7:35072

Error: Tests run: 1874, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1,800.32 s <<< FAILURE! - in TestSuite
Error: testTwoQueriesAtSameTime(com.facebook.presto.execution.resourceGroups.db.TestQueuesDb) Time elapsed: 60.014 s <<< FAILURE!

Often fails. This is the last change that touched this code. Could this be a regression or should the test be just disabled ?