avoid mutable references in critical_section_mutex implementations

[davidhewitt]

There is a slight technicality in with_critical_section_mutex2 that if the same PyMutex is passed as both arguments, the &mut references to the raw ffi mutex internally are UB due to mutable aliasing.

Fortunately we can just work with raw pointers here as this is an FFI call. I'm not sure wether the compiler actually will produce exploitable UB in this particular position due to the references being immediately coerced to pointers for the FFI call, but it seems wise to tidy this up.

cc @ngoldbaum

(Credit to Codex security scanning for this discovery.)

[davidhewitt]

While we're here, I think we might be able to replace these core::mem::zeroed() with MaybeUninit of some form, to avoid needing to zero-intialize the structures at each critical section entry.

Looks like the C headers don't zero-initialize:

https://github.com/python/cpython/blob/a7ed0c9e1dee1397e80e2e0d90d110155da2bc30/Include/critical_section.h#L74-L90

[davidhewitt]

(Possibly better to defer this to a separate PR given correctness / performance implications are not related to the exact diff here.)

[ngoldbaum]

Thanks! There is another followup (pointed out to me by Claude when I asked it to review this), which is that the critical section API allows possible UB by passing the same mutex twice and calling get_mut and then get (so there is a simultaneous mutable and immutable reference). We should probably tighten the API to prevent that.

It's already unsafe of course but we should also prevent footguns or at least document them in the safety contract :)