adds validateWithLevel API for CedarJava

[muditchaudhary]

Overview

Introduces validateWithLevel API in CedarJava, matching the functionality of Cedar Policy's validate_with_level (RFC 76).

Changes

CedarJava Layer

• Implements new validateWithLevel API with comprehensive test coverage
• Maintains interface consistency with existing validation methods i.e., exposed through AuthorizationEngine and responses as ValidationResponse

CedarJavaFFI Layer

• Implements validate_with_level FFI method in src/helpers.rs (Ideally should belong in cedar_policy::ffi. See Note below)
• Borrows some implementation from cedar_policy::ffi for consistency
• Maintains the same interface structure as existing validate calls from cedar_policy::ffi
• Adds tests added to verify FFI behavior

Example Usage

// Policy
permit(
  principal in UserGroup::"alice_friends",
  action == Action::"viewPhoto",
  resource
) when {principal in resource.owner.friend};

// Sample Output
ValidationResponse(
  validationErrors = [
    Error(
      policyId=policy0, 
      error=DetailedError{
        message="for policy policy0, this policy requires level 2, which exceeds the maximum allowed level (1)",
        help="",
        code="",
        url="",
        severity=,
        sourcelocations=[SourceLabel{label="", start=122, end=143}],
        related=[]
      }
    )
  ],
  validationWarnings = []
)

Note

The validate_with_level FFI implementation currently resides in CedarJavaFFI to facilitate inclusion of this feature in the CedarJava 4.4 release. This approach avoids waiting for the next minor version release of cedar_policy (likely 4.6). A near future PR will move this functionality to cedar_policy::ffi. Once validate_with_level API is exposed through cedar_policy::ffi we can remove its implementation from CedarJavaFFI in a subsequent release.

Next Steps

• Create a separate PR for moving validate_with_level to cedar_policy::ffi (I'll do it)

If review scope is too large, this PR can be split into separate FFI and Java contributions

[muditchaudhary]

This should/will belong in cedar_policy::ffi. See Note in the PR description.

[mark-creamer-amazon]

Nit as an aside: Looks like this is how we do it in most places, but here it looks like we print it differently.

I wonder what our appetite for using something like Lombok to improve boilerplate like this and getters/setters is: https://projectlombok.org/features/NonNull

[muditchaudhary]

Yeah, there is some inconsistency in the message. I followed the message that we use in ValidationRequest constructor.

Maybe we can do a Lombok "campaign" to avoid inconsistency across CedarJava before the release.

[john-h-kastner-aws]

note: once moved into cedar_policy crate these clones should be avoidable