Created attachment 320951 [details] [review]
patch

The integration is already so tight, there is no reason to
not further formalize it!

An element will always get a clock set on it in a "normal" context from the parent pipeline, and we found that in the tests where we don't care about the clock, the testclock does not get in the way, and in all the tests where we *do* want a clock, we will save the extra line of code to set it on the element.

Not explicitly wanting a clock to be able to test no-clock scenarios is the more unusual case, and to then have to explicitly do things like gst_element_set_clock (element, NULL) makes this more explicit and better.

There are also some cases where you want to use the systemclock (stress-tests or not bothering with determinism), and this then will need a call to gst_harness_use_systemclock() which is fair.