Add a rate_applies_when field to policy rules

[jiffyclub]

Is your feature request related to a problem? Please describe.

As I've dug into policies and #658 especially I've discovered that there's no guidance about when a fee/subsidy associated with a policy should be applied to an event. Is it when the event is in violation of the policy, or when it's in compliance? And in the discussion in #658 I think we've made clear that for some rules one way makes more sense, and in others the other way, so I don't think there's one best way to go.

Describe the solution you'd like

Instead of picking one convention or the other I think we could have a rate_applies_when field on policy rules that could have values of violation or compliant that would make this explicit on a per-rule basis.

Is this a breaking change

A breaking change would require consumers or implementors of the API to modify their code for it to continue to function (ex: renaming of a required field or the change in data type of an existing field). A non-breaking change would allow existing code to continue to function (ex: addition of an optional field or the creation of a new optional endpoint).

• No, not breaking

Impacted Spec

For which spec is this feature being requested?

• policy

Describe alternatives you've considered

The alternative I've considered is to pick either compliance or violation as the standard for applying a rate to an event. People would have to structure their rules such that applying the standard would have the desired outcome. I'm not a fan of that, though, because I think some fee rules have to be constructed in counter-intuitive ways when you have to choose one way or the other (see discussion in #658). By letting people specify how rates are meant to be interpreted alongside their rules they can write rules in the ways that make sense to them.

Additional context

N/A.

[avatarneil]

I think this is definitely an interesting idea (essentially allowing the flipping of positive vs negative association). I do think that if we introduce this concept (or something along these lines), we may want it to live at the Policy level as opposed to the Rule level. I can definitely imagine some weirdness if you have one Policy which has rules using different association tactics, specifically when thinking about count policies where you may have some overflow (e.g. https://github.com/openmobilityfoundation/mobility-data-specification/blob/main/policy/examples/provider-cap.json).

I'm sure I'll have more feedback after I think about this some more, I just noticed this issue a few minutes ago!

[schnuerle]

Completed with #688. Thank you all!