Add PWM sensor to thermal task

[mkeeter]

(staged on top of #2428)

This adds a new fan_ctrl sensor, which is updated by the thermal loop. In combination with oxidecomputer/humility#602, we can log both fan speed (which was already possible) and commanded PWM values with humility dashboard -o out.csv

Here's an example while running stress-ng:

The hysteresis from the fan controller is quite noticeable if we plot PWM vs RPM:

[hawkw]

I kinda wonder if maybe we ought to just make self.set_pwm also post the new duty cycle to the sensors task, so that it's impossible to set the duty cycle without also posting value to the sensors task?

[mkeeter]

Done – it's a little awkward (because we need to represent the NoData::DeviceOff case), so I switched the input argument to a Result<PWMDuty, NoData>.

[hawkw]

Hmm, did we have to do it like that? I was imagining that in the DeviceOff state we would just call self.sensor_api.post directly. Rather than making set_pwm the only way we ever post a sensor reading, I was just thinking that any time we set the PWM duty cycle we also post a sensor reading (but this would not be the only place we posted a sensor reading). set_pwm(Err(NoData::DeviceOff)) feels a bit awkward to me.

[mkeeter]

I think the Result<..> shenanigans are the simplest way to do it. In our previous world where set_pwm just takes a PwmDuty, when we go uncontrollable, we'd still call set_pwm(PwmDuty(0)) – and would therefore post 0 to the sensors task because we don't know any better.

The Result<..> argument lets us distinguish between "there's an error, so post the error but set the PWM to 0" versus "situation normal, post a pwm of 0 and set it".

[hawkw]

Oh I see, yeah, okay. I don't hate it.

[labbott]

just a few minor questions but LGTM

[labbott]

It feels strange to treat DeviceOff as an error. Under what circumstances would we hit PowerDown?

[labbott]

Nit: the command part of this description feels weird. Just drop it?