thermal: distinguish between real and made up temperatures

[hawkw]

Presently, the thermal task's ringbuf attempts to gaslight the reader
by presenting totally fake temperatures as though they were real
measurements from a sensor. This is because the thermal loop contains
logic which attempts to extrapolate a worst-case temperature projection
based on the last temperature reading received from a device and the
time which has elapsed since that reading:

hubris/task/thermal/src/control.rs

Lines 508 to 526 in ddfb878

	/// Returns the worst-case temperature, given a current time and thermal
	/// model for this part.
	///
	/// This only matters when samples are dropped or if there is significant
	/// lag in the sensors system; if we received a reading on this control
	/// cycle, then time_ms ≈ now_ms, so this is close to v.value (i.e. the most
	/// recent reading).
	///
	/// Typically, time_ms is earlier (less) than now_ms, so this subtraction is
	/// safe. If there's invalid data in the sensors task (i.e. readings
	/// claiming to be from the future), then this will saturate instead of
	/// underflowing.
	fn worst_case(&self, now_ms: u64, model: &ThermalProperties) -> Celsius {
	Celsius(
	self.value.0
	+ now_ms.saturating_sub(self.time_ms) as f32 / 1000.0
	* model.temperature_slew_deg_per_sec,
	)
	}

This logic is not wrong, per se. Extrapolating a worst-case
temperature is the correct behavior in the absence of sensor data, even
when it leads to a thermal shutdown which is not actually necessary: the
thermal loop is correct to assume the worst in the absence of real data.
However, the way we presently present these fake temperatures in the
ringbuf is very confusing to the reader, as they appear to be real
life temperature measurements that actually came from the device.
Recently (see #2385), this reporting of fake temperatures as though they
were real lead @nathanaelhuffman and I to hypothesize about a
manufacturing defect with T6 heatsinks when the actual issue was just
that we couldn't read the NIC's temperature sensor as it had MAPO-ed a
while ago (see #2384).

This commit is my attempt to make the ringbuf entries less misleading.
Now, in addition to recording the worst case estimate that lead to a
thermal control state transition (to the Critical or Uncontrollable
states), we also record the real temperature reading from the device
alongside it. The names of the ringbuf fields now attempt to indicate
which is a real temperature and which is a worst-case estimate.

Note that the fake temperatures are only presented to a reader as though
they were real in the thermal loop's ringbuf; they are not sent to the
sensors task and will not be reported externally through the
control-plane-agent's component_details or read_sensor_value APIs.
Instead, we will just report nodata_now to the sensors task when
encountering an error reading a sensor measurement --- which is correct.
See:

hubris/task/thermal/src/control.rs

Lines 881 to 901 in ddfb878

	match s.sensor.read_temp(self.i2c_task) {
	Ok(v) => self.sensor_api.post_now(s.sensor.sensor_id, v.0),
	Err(e) => {
	// Record an error errors if the sensor is not removable
	// or we get a unexpected error from a removable sensor
	if !(matches!(
	s.ty,
	ChannelType::Removable
	| ChannelType::RemovableAndErrorProne
	) && e
	== SensorReadError::I2cError(
	ResponseCode::NoDevice,
	))
	{
	ringbuf_entry!(Trace::SensorReadFailed(
	s.sensor.sensor_id,
	e
	));
	self.err_blackbox.push(s.sensor.sensor_id, e);
	}
	self.sensor_api.nodata_now(s.sensor.sensor_id, e.into())

So, only the ringbuf must be changed to make this less misleading.

Fixes #2385

[hawkw]

https://www.youtube.com/watch?v=GM-e46xdcUo

[hawkw]

I split this into its own ringbuf entries because adding two more 32-bit fields to CriticalDoTo and PowerDownDueTo would have probably made them the largest ringbuf entry and made each ringbuf slot a word bigger, which I wanted to avoid.