Resource Isolation Feature Checkpoint 4: Extend cache warmup to allow multiple resource isolation groups and multiple replicas

[ctbrennan]

Why I'm doing:

This is part of the implementation of the Resource Isolation for Shared Data Mode feature

What I'm doing:

Makes syntax and functionality changes to CACHE SELECT statements to allow caching data for specified resource isolation groups and more than one replica.

They can now be of the form

CACHE SELECT <column_name> [, ...]
FROM [<catalog_name>.][<db_name>.]<table_name> [WHERE <boolean_expression>]
[PROPERTIES("verbose"="true", "resource_isolation_groups"="<GROUP_ID_1>,...,<GROUP_ID_N>", "num_replicas"="<NUM_REPLICAS>")]

If no resource_isolation_groups are specified, uses the resource group of the current frontend.
If no num_replicas, we assume 1.

Fixes #issue https://jira.pinadmin.com/browse/RTA-6269

What type of PR is this:

• BugFix
• Feature
• Enhancement
• Refactor
• UT
• Doc
• Tool

Does this PR entail a change in behavior?

• Yes, this PR will result in a change in behavior.
• No, this PR will not result in a change in behavior.

If yes, please specify the type of change:

• Interface/UI changes: syntax, type conversion, expression evaluation, display information
• Parameter changes: default values, similar parameters but with different default values
• Policy changes: use new policy to replace old one, functionality automatically enabled
• Feature removed
• Miscellaneous: upgrade & downgrade compatibility, etc.

Checklist:

• I have added test cases for my bug fix or my new feature
• This pr needs user documentation (for new or modified features or behaviors)
  • I have added documentation for my new feature or new function
• This is a backport pr

Bugfix cherry-pick branch check:

• I have checked the version labels which the pr will be auto-backported to the target branch
  • 3.3
  • 3.2
  • 3.1
  • 3.0
  • 2.5

[zhenxiao]

looks good
a few small things

[zhenxiao]

shall we add a TODO: if requesting more replicas than available, shall we trigger a replica load task, from S3 to compute node

[ctbrennan]

Not totally sure what you mean by "replica load task", that basically describes what is already being executed here. Are you saying we should schedule it for later, if/when we have more compute nodes available? I don't think that's a good approach necessarily.

My thinking is this: if we're requesting more replicas than we have compute nodes, we can't fulfill the intention of the statement, so I'm throwing an exception. The other option is to make a best-effort attempt and select all of the available compute nodes.

[zhenxiao]

looks good
one minor suggestion

[zhenxiao]

Shall we use a more intuitive naming? e.g. getWorkerFromUnmatchingIsolationGroup?

[ctbrennan]

This specific function isn't getting any worker, it's signaling the intent to allow getting any worker.