Adds Entities with backward compatibility

[muditchaudhary]

Description

This PR introduces the Entities class to CedarJava, aligning it more closely with CedarRust's implementation. Key changes include:

1. New Entities class: Replacement for the current Set<Entity> representation for entity collections. This new class is equivalent to CedarRust's Entities.

2. Parse Entities from JSON: The Entities class supports parsing entities from both JSON strings and files.

3. Updated authorization methods:

   • Overloaded isAuthorized() and isAuthorizedPartial() methods to accept the new Entities type.
   • Maintained backward compatibility by retaining support for Set<Entity> in existing method signatures.

4. Testing:

   • Added unit tests for the new Entities class.
   • Implemented tests to verify backward compatibility of authorization calls using both Entities and Set<Entity>.
   • Introduced org.skyscreamer:jsonassert:2.0-rc1 as a test dependency
     • Enables semantic comparison of JSON structures needed to test Entities using JSONAssertEquals().
     • Provides foundation for future JSON-related testing needs (e.g., .toJson() methods).

[mark-creamer-amazon]

Does this style match the behavior in Rust where each is printed on a new line?

[muditchaudhary]

No. The default behavior in Rust is to display the JSON representation of Entities and Entity. .toString() for Entities continues to follow the same display format which was implemented for Entity

[muditchaudhary]

It seems like this format for displaying Entity was introduced in CedarJava 2.x. Maybe we can make the behavior similar to Rust in the next major version update as this will change the behavior of an existing public API

[adpaco-aws]

Are there no plans to deprecate the methods using Set<Entity> in favor of these new ones? It's great to have these APIs but at the moment it's not clear why anyone would use one over the other.

[muditchaudhary]

Are there no plans to deprecate the methods using Set<Entity> in favor of these new ones? It's great to have these APIs but at the moment it's not clear why anyone would use one over the other.

Currently, we have not decided the concrete version when we plan to deprecate the methods using Set<Entity>. The introduction of Entities serves two main purposes: First, it establishes the foundation for accessing CedarRust Entities APIs (such as is_ancestor_of, ancestors). Second, it simplifies the process of loading entities from files/strings, reducing the burden on users who currently need to create entities programmatically. While both approaches will coexist for now, the Entities implementation offers/will offer these additional capabilities that might be useful for the users over time.