RANGER-5848: Add constraints to RangerAccessResult

[vyommani]

What changes were proposed in this pull request?

RANGER-5848: add constraints to RangerAccessResult, so plugins and callers (such as the Agent Harness) can start integrating with constraint results before policy evaluation lands. This was split out of #1316 per review.

Stacked on #1309 (RANGER-5838). Policy evaluation, which populates these constraints, follows in #1316 (RANGER-5842).

RangerConstraintResult (new)

• Fields: constraintName, parameters (copied on construction), policyId, policyVersion, policyPriority, matchType.

• CONSTRAINT_RESULT_COMPARATOR orders by:

  • constraint name;
  • policy priority, higher first (same order as RangerPolicyEvaluator's comparators, so OVERRIDE comes before NORMAL);
  • match type;
  • policy id.

  This lets enforcement pick the applicable constraint.

RangerAccessResult

• New getConstraints() (returns an empty list when there are none), setConstraints() (copies the list) and addConstraint().
• Constraints are copied in setAccessResultFrom() and cleared when the result becomes a deny (setIsAllowed(false)).
• Included in toString().

RangerBasePlugin

• When a chained plugin's result overrides the base result and is allowed, its constraints are copied into the final result.

No behavior change: the policy engine doesn't populate constraints yet, so getConstraints() is always empty until #1316.

How was this patch tested?

New unit tests (8):

• TestRangerConstraintResult:
  • null parameters become an empty map, and input parameters are copied;
  • equals/hashCode/toString include policyPriority;
  • comparator ordering by name, priority (higher first), match type and policy id.
• TestRangerAccessResult:
  • empty by default, and addConstraint(null) is ignored;
  • setConstraints() copies the input list;
  • setAccessResultFrom() copies constraints;
  • deny clears constraints.

mvn -pl agents-common checkstyle:check test