FFI nits

[khieta]

Description of changes

A variety of small updates to the FFI to move us closer to completing #757. Downstream breaks expected.

• In the validation FFI, changed policy_set to policies for consistency with the authorization FFI.
• Standardized on using PolicyId for policy ids instead of SmolStr.
• Re-exported JsonValueWithNoDuplicateKeys in the public FFI API.
• Switched to using camelCase for ValidationMode and Decision. This will impact the current serialization of decisions & will likely lead to downstream breaks.
• Updated ValidationSettings to match the proposal in Cedar FFI Overhaul #757. Also updated the logic so that the "enabled" flag is actually used for something.
• Since this PR already makes a change that requires updating the integration tests (namely "Allow" → "allow"), I snuck in another breaking change to switch the integration tests to use camelCase.

Issue #, if available

#757

Checklist for requesting a review

The change in this PR is (choose one, and delete the other options):

• A breaking change requiring a major version bump to cedar-policy (e.g., changes to the signature of an existing API).

I confirm that this PR (choose one, and delete the other options):

• Updates the "Unreleased" section of the CHANGELOG with a description of my change (required for major/minor version bumps).

I confirm that cedar-spec (choose one, and delete the other options):

• Requires updates, and I have made / will make these updates myself. (Please include in your description a timeline or link to the relevant PR in cedar-spec, and how you have tested that your updates are correct.)

Note: Also require updates to cedar-java and cedar-integration-tests.

[john-h-kastner-aws]

This makes the experimental modes visible in the ffi api where they weren't before. That probably a good thing, but worth thinking about whether that could go wrong.

[khieta]

This shouldn't break anything since the WASM code directly uses the Rust FFI definitions. It should just silently add support for the new validation modes if the cedar_policy crate is compiled with the appropriate flags. What other complications were you thinking of?

[andrewmwells-amazon]

I think they should be visible in the FFI.

[john-h-kastner-aws]

Not sure I like this. We went through some effort previously to catch this duplicate key case, and I think that was the right thing to do.

[khieta]

My thinking was that we want the FFI to use simple types where possible, and users can decide how to handle duplicates when they construct the serde_json::Value.

The other option is to move JsonValueWithNoDuplicateKeys from core to the public API -- would you prefer that?

[andrewmwells-amazon]

IIRC, we decided downstream users should handle duplicates as they see fit. So in principle I'm fine with moving JsonValueWithNoDuplicateKeys to the public API. I'm not sure this will help anyone using the FFI though because they'll still likely use an equivalent of serde_json::Valueon the other side of the interface.

[khieta]

Returning to working on this PR! 😄

The latest commit re-exports the JsonValueWithNoDuplicateKeys type, as discussed in comment threads and in-person. Remaining outstanding question on my end is: Are we ok with the switch from PolicyId →SmolStr, or would we prefer to standardize on PolicyId?

[cdisselkoen]

Slightly prefer PolicyId, but happy with either one. Either way, I expect we'll keep tsify(type = "string"), so we're not really getting additional semver flexibility (the PolicyId type isn't really opaque at the FFI layer). So using the PolicyId name would just be for documentation purposes, as I understand it, and because serde would do the right thing automatically, making it slightly more convenient to implement the FFI layer.

[khieta]

Latest version standardizes on using PolicyId instead of SmolStr. The downstream fix for cedar-spec is in cedar-spec#346 -- I'll work on the updates needed for cedar-integration-tests and cedar-java tomorrow.