Create a RsOpenLEADR module

[rnijveld]

Describe your changes

This is a work in progress draft implementation for OpenADR 3.0 using openleadr-rs. The goals here would be:

• Allow configuration of a specific OpenADR program and some basic filtering on the events from that program
• Create a timeline for the IMPORT_CAPACITY_LIMIT and PRICE types OpenADR specifies and send those values to everest using the external_energy_limits interface
• Have a scheduled update of the energy limits such that any updates in OpenADR are reflected in everest (not using a subscription mechanism right now, as that mechanism is likely to change in the near future)

To do this, we need two mechanisms implemented that aren't in openleadr-rs:

• Starting up an async runtime, given openleadr-rs is async whereas everest is not
• A way to schedule the retrieval of new values from the OpenADR VTN

I've attempted to implement these two parts, but have not yet implemented the sending of updated values using the external_energy_limits interface.

Issue ticket number and link

Checklist before requesting a review

• I have performed a self-review of my code
• I have made corresponding changes to the documentation
• I read the contribution documentation and made sure that my changes meet its requirements

[dorezyuk]

not sure if I understand the while loop here

[dorezyuk]

ah draft

[rnijveld]

This is basically a way to handle two things: any suspend-state that a system might end up in, in which case the monotonic clock these timers are based upon aren't advancing or when an NTP daemon does clock adjustments using jumps, which also doesn't affect the monotonic clock that is used for timers in Linux.

The sleeps we are working with here are generally pretty large (in the order of a day or even a week), and just setting a timeout for 86400 seconds might result in overshooting the target time significantly given the previously mentioned problems. This implementation is an attempt to not overshoot the target time while at the same time not completely falling back to a busy loop. A better solution would of course be if the underlying system offers a way of waking up the process when a certain time is reached, but I don't think everest offers such an interface?

Having said all that: I'm not sure how much I should really be worrying about these problems at all, and I could just as well remove this code altogether if desired :)