Rate limiting for scheduling

[nhoening]

Scheduling is the first operation we should start to rate-limit, as it is most expensive. Foremost, this protects against bad/rogue client implementations.

My suggestion (taking into account the state before Project 6 is implemented:

• Make a new field on GenericAssets: max-actuation-rate (a timedelta). How often we allow someone to re-compute things for their asset is a business decision I believe, so this is where it belongs.
• Update the sensor/<id>/schedules/trigger endpoint, so it checks when the last scheduling job happened and if it was too recently, it does not make a new one, or it schedules one into the future (in this option we also need to check if in the future a scheduling job already exists).

[nhoening]

Curious to hear @Flix6x thoughts.

[Flix6x]

I like it. I think this parameter would also be suited for being coupled to the organisation account instead: for example, a "plan" JSON column for Accounts similar to our "attributes" JSON column for GenericAssets.

[nhoening]

I agree that this has consequences for the "plan" of customers, as pricing could be derived from this (among other things).

Why a JSON column?

Also, they might want to rate Assets differently within their account.

[Flix6x]

Why a JSON column?

A max_actuator_frequency field feels like it would be part of a blob of attributes assigned to something.

they might want to rate Assets differently within their account.

True. I'd start with implementing the default value on the Account plan, and we could consider whether it makes sense to write plan searching logic like we have attribute searching logic on the Sensor class, which first checks whether the attribute exists on the Sensor, and if it doesn't, looks for the attribute on the GenericAsset. Similarly, we could elevate a plan attribute search on the GenericAsset to a plan attribute search on the Account.

[nhoening]

A max_actuator_frequency field feels like it would be part of a blob of attributes assigned to something.

Well, in relational databases, we'd usually make a table called "plan", with a foreign key to Account, and store plan details there. That's what I'd recommend.

[Flix6x]

Implemented in #2306 (which supersedes the tech spike in #587).

Following the discussion above, the limit is configurable per account through a rate_limits account attribute, which takes precedence over the server-wide config — the 'plan' idea, without needing a migration. And since how often it is reasonable to re-compute a schedule is a business decision, the host chooses what shares a budget via FLEXMEASURES_API_RATE_LIMIT_KEY: per asset (default), per account, or per user.