Allow empty tiered replicants map for load rules

[adarshsanjeev]

This PR makes some changes around the allowed tiered replicants for load rules. It allows values empty tiered replicant in load rules, which would translate to the segment being marked as used, but not loaded on any historical for example:

For backwards compatibility, a new flag "allowEmptyTieredReplicants" is also added. If the flag is false or missing, the old behaviour of converting an empty map to the default load rule is maintained. If it is true, which would be the case going forward, empty load rules are allowed.

{
    "interval": "2019-08-25T12:00:00.000Z/2019-08-26T00:00:00.000Z",
    "type": "loadByInterval",
    "allowEmptyTieredReplicants": true
}

The above load rule would not be loaded on the historical as per the new behaviour.

Exceptions thrown during validation are returned to the user.

---

This PR has:

• been self-reviewed.
  • using the concurrency checklist (Remove this item if the PR doesn't have any relation to concurrency.)
• added documentation for new or modified features or behaviors.
• a release note entry in the PR description.
• added Javadocs for most classes and all non-trivial methods. Linked related entities via Javadoc links.
• added or updated version, license, or notice information in licenses.yaml
• added comments explaining the "why" and the intent of the code wherever would not be obvious for an unfamiliar reader.
• added unit tests or modified existing tests to cover new code paths, ensuring the threshold for code coverage is met.
• added integration tests.
• been tested in a test Druid cluster.

[kfaraz]

I think this change is backwards incompatible. There must be several clusters using null which internally gets converted to the mapping _default_tier => 2. You are now converting these to the mapping _default_tier => 0 in the LoadRule.run() method. This will cause unexpected behaviour in all such clusters.

I can think of some alternatives:

Option 1 (preferable)

• Continue to treat null as a special and convert it to _default_tier => 2 as before
• Also allow empty in the LoadRule.run(). It would automatically translate to mean the segment need not be loaded anywhere.
• Allow 0 replicas to be specified for any tier for the same backward compatibility reasons. I don't think this affects the coordinator behaviour in any way.

The only con of this method is that null and empty have different meanings.

OR

Option 2 (not very user-friendly)

• Keep everything as is.
• We must specify mapping for at least one tier even it we don't want segment to be loaded anywhere.

Option 3 (reserve a special tier name)

• Similar to option 2 but use a special tier-name which can be mapped to 0 instead of an actual tier in the cluster.

@adarshsanjeev , @cryptoe , what do you think?

[adarshsanjeev]

I think Option 1 has the potential to be confusing. For example

  {
    "type": "loadByInterval",
    "tieredReplicants": {},
    "interval": "2010-01-01/2020-01-01"
  }

and

  {
    "type": "loadByInterval",
    "interval": "2010-01-01/2020-01-01"
  }

would result in one loading the segments on historicals and one would not, which would end up being difficult to understand moving forward.

[cryptoe]

We could also include a new flag called allowNullTieredReplicants which is defaulted to true and does not change the current behavior ie we set the default tier rules in case NullTieredReplicants is null.

If users set this to false the new behavior is enabled. The web-console starts setting this new flag for every request. That would solve the backward compatibility piece.
Its Option 1 with a new flag.

cc @kfaraz @adarshsanjeev

[cryptoe]

Just suggested a new name.

[kfaraz]

Minor changes required.

[cryptoe]

Overall lgtm!!
Will merge once @kfaraz gives his approval.

[kfaraz]

Thanks for the changes, @adarshsanjeev !

[abhishekrb19]

LGTM. Do we want to document the new parameter useDefaultTierForNull: https://github.com/apache/druid/blob/master/docs/operations/rule-configuration.md?