Admins should have a playground to test a Subject against a Subject Condition Set

[jakedoublev]

This issue is WIP.

Background

There is a desire to support multiple sources of truth to associate a Subject (user, PE, NPE) via Subject Condition Sets (SCS) and their Subject Mappings (SM) to Attribute Values on data resources. These may look like:

1. Identity Provider (idP) Access Tokens
2. idP user info
3. trusted PEP-derived context
4. fetched data from an external source (i.e. a platform owner's external /userSettings or /userInfo endpoint for the rest of their services)

When admins are creating Subject Condition Sets and their mappings to values, they should have a playground to test that with: a) a test input of any of those sources of external Subject context (as they are supported) and b) a test Subject Condition Set, there is a logical match of the SCS for the Subject. For example:

Example playground test "match/no match" scenarios:

Subject: copy/pasted JWT access token
Selection: checkbox of idP plugin to load (and probably its running endpoint)
SCS: test SCS

Subject: copy/pasted list of fields/values (assumed to be a PEP-driven flow where the PEP can attest to the user)
Selection: empty/default
SCS: test SCS

Subject: copy/pasted JWT access token
Selection: data fetcher
SCS: test SCS

This is distinct from an access decision playground like ABACUS because it would be isolated to testing any dynamic idP plugins, any selector syntax in the subject_external_fields in the SCS, and any AND/OR/IN/NOT_IN logical matching within the SCS. A playground like ABACUS tests one level higher where a Subject's matched attribute values are already resolved through the mappings and the test is pairing Data attributes with Subject attributes to make a decision. It is likely this playground could exist within the higher level playground to e2e test Subject -> SCS/SM -> attribute values -> + data attributes -> access decision, but it should also exist and be able to be run independently.