Should we track redundant chaninfo .unitmapping[ix].bValid on incoming CHANREPSPKHPS packets?

[cboulay]

Based on my notes, the device responds to CHANREPSPKHPS packets by setting the spike hoops, but it also sets the chaninfo .unitmapping[unid].bValid field equal to chaninfo's .spkhoops[unid][0].valid.

Do we need to track this particular field when mirroring the device state in pycbsdk? The device uses this field to determine if it should bother checking if a spike meets hoop criteria. I suppose another client software using pycbsdk might do the same if we don't otherwise mark this field as deprecated or unused.

---

I think we don't need to worry about properly setting this .bValid field when sending a config packet because the device overwrites the field with the 0th hoop's .valid anyway.