drm/output: Allow DrmOutput destruction during manager-lock

[Drakulix]

Since #1778 we provide an api to explicitly lock the DrmOutputManager to apply multiple changes atomically without DrmOutputs being able to observe any inconsistent state.

However as a side-effect of this, it has become impossible to re-assign a crtc to a different connector in one atomic opertion, as the lock on the DrmOutputManager prevents the Drop-implementation of DrmOutput to free any crtcs for re-use. This is a problem in cosmic-comp currently, when trying to apply a new configuration in one go on more resource constraint systems leading to a rejection of the entire configuration.

This commit introduces a channel to defer freeing the crtc to the locked manager, if locking fails. Since this can be racy, we rely on the event-loop to free up any crtcs stuck in said channel. Synchronization with different threads for dropping the DrmOutput still needs to be handled by downstream (e.g. by joining said thread).

I'd like to get some feedback on this approach. I also tried to fix this issue without involving the event-loop by using additional CondVars and other synchronization primitives, but that grew very complex to the point where we might as well build our own RwLock for this specific purpose.

[Paraworker]

Hey, I’m wondering whether crossbeam-skiplist::SkipMap would help here. From the description, locking the entire map seems like a broader scope than necessary. Would it be sufficient to take a lock on a single compositor and perform a series of atomic operations there?