"Race" when (de)activating pads

Submitted by Edward Hervey `@bilboed`

Currently the following scenario can happen.

Thread 1 (from downstream elements) wants to reconfigure the scheduling mode of an upstream element (such as typefind)
Thread 2 (from the application or higher-level element) wants to deactivate the scheduling of that element.

The following "race" happens:

T2 calls gst_pad_set_active(pad, FALSE)
** T2 calls activate_mode_internal(pad, ..., FALSE)
** T2 pad was currently active, it eventually calls pre_activate(pad, GST_PAD_MODE_NONE), which sets in_activation to TRUE and GST_PAD_MODE(pad) to GST_PAD_MODE_NONE
** T2 calls the actual activation function
T1 calls gst_pad_activate_mode(pad, ..., TRUE)
** T2 calls activate_mode_internal(pad, ...., TRUE)
** T2 has GST_PAD_MODE_NONE, so carries on to call pre_activate
** T2 in pre_activate sees that in_activation is TRUE, so waits for the other thread to finish (and set in_activation to FALSE)
T2 finished calling the actual activation function and calls post_activate
** T2 set in_activation to FALSE and resumes succesfully, i.e. telling the caller that the pad is deactivated
T1 can resume activation and actually activates the pad

=> T2 assumes the pad is deactivated .... but it's not. (Note that the exact opposite could also happen).

Not entirely sure how this could be solved though.