Pull system state notion out of Jefe?

The reference implementation supervisor task (jefe) currently maintains a notion of system state, which other tasks can query and be notified about. To keep Jefe board-and-application-independent and reduce coupling, it stores a u32. This means that any application-layer state type needs to be convertible to and from u32.

That's sort of arbitrary.

The reason system state lives in Jefe in the first place is

1. It seems like a fairly general idea (not Oxide-specific)
2. Jefe can't restart, so its RAM never gets reinitialized without a system reset

However, since then, we've built a general purpose "stuff store" in packrat. It might make sense to remove the system state idea from Jefe and move it into packrat, which is also not intended to restart at runtime. This would allow applications to use an arbitrarily complex type for state rather than getting 4 bytes to work with.

On the down side, any application that needs a notion of state now needs another task (packrat or something like it), which might be a problem on Very Small Processors.

Something to think about.

From a discussion with @jgallagher .

Start by reading the Jefe and packrat task implementations and tracing how system state is stored, queried, and used for notifications. Compare the resource cost and restart behavior of each approach, then define the application-facing state API and identify affected users before proposing a change.