Use lock_api trait for configurable PDI lock

[theol0403]

Hey, it's me again :).

Following our conversation on matrix regarding realtime performance on linux, I was able to tune the performance of my system by using blocking timers that inherit the PREEMPT_RT priority of my PDI loop thread instead of smol's timers that delegate timing to a non-RT helper thread.

Before:

After:

That looks way better... but wait, why is there still a spike!?

Via debugging, I was able to determine that occasionally, let mut pdi_lock = self.pdi.write(); in subdevice_group/mod.rs would take 2-20ms acquire the lock, despite being a high priority thread. We've run into the problem of priority inversion, where my application-layer non-RT threads that want to write and read to the PDI (theoretically an instantaneous operation) get pre-empted while still holding the lock, causing the PDI loop thread to hang.

There are various approaches to solving priority inversion, including os-provided mutexes that upgrade/inherit the priority of any lower-priority thread currently holding the lock (eg futex), or RT-specific algorithms that do dependency analysis or simply yield on lock instead of spinning.

Some available mutexes that address this issue to various extents (with mixed results):

• https://docs.rs/rtsc/0.3.17/rtsc/pi/index.html
• https://docs.rs/parking_lot_rt/latest/parking_lot_rt/
• https://docs.rs/priority-inheriting-lock/latest/priority_inheriting_lock/
• https://docs.rs/rustix-futex-sync/latest/rustix_futex_sync/

For example, patching ethercrab to use rtsc::pi::Mutex, we get the following!

However, I would like to reduce the number of patches I need to maintain in a fork.

This PR takes advantage of lock_api to expose a user-configurable PDI lock in ethercrab that defaults to the current spin lock. This way, various locking implementations (rt, non-rt, critical section, etc) can be easily swapped out.

[theol0403]

Might be able to avoid any breaking changes by having R be the last parameter in SubdeviceGroup, defaulted to crate::DefaultLock, but it feels off as S and DC are marker types whereas currently the first three are proper parameters.

On the other hand, it is more common to specify Op and HasDc if you want to store the groups somewhere, but less common to override the lock type, so maybe I should put R as the last parameter.

[jamwaffles]

The analysis and investigation in your opening comment is fantastic! Nice work finding the root cause and... oof... that default locking behaviour is terrible.

Concerning the order of generics, I'd like to at least explore removing the S typestate as it's making the API a bit too restrictive IMO, so I don't think we need to worry about the generics order for now.

I've got a few changes I'd like to make, but other wise this is great stuff, thanks!