Remove "rate" as a rule type

[jiffyclub]

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

I'm having trouble wrapping my head around the idea of "rate" rule. Rates don't exist in a vacuum, they apply to something else and that something else is more at the heart of the rule. And as we're seeing in #631/#658, we've ended up wanting rates in conjunction with other rule types, not as a standalone rule.

Describe the solution you'd like

What if we got rid of the rate rule entirely and only had rule types based around the physical concept to which the rate applies? The policies in #658 are time rules. So is this parking fee example. I think a per trip fee could be a count rule, or maybe a new per_unit rule.

Rules could then have a rate/fee/cost (open to suggestions) section that describes anything monetary associated with the rule. This would be basically the same as the rate info that's currently in rules, but could also contain a field that describes whether the cost is meant to be applied to events in compliance with the rule or events in violation of the rule, clearing up some confusion we've discussed in relation to #658 (see #666). (I'd like this monetary section to be a sub-section of the rule, not at the top level as it is now, but that's a separate discussion I'll open an issue about. See #663.)

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).

• Yes, breaking

Impacted Spec

For which spec is this feature being requested?

policy

Describe alternatives you've considered

There are example policies and #658 that mix rates with other types of rules while using the rate rule type, so we could stick with this existing system where only rules of the rate type have monetary costs (or subsidies) associated. But, as outlined here and in #631, I don't think that's working well.

Additional context

N/A