Always get the AGGREGATE lock when pausing and starting the task
Avoid using bus_poll and instead get_state blocking, it will do almost the same thing but no run a GMainLoop.
Add a seek test with 50 sources -- so we check if we can scale up.
Ensure the buffer on a pad can not be consumed while we are inside ->aggregate()
Seeking 500 times with 50 pads times out, not doing that + cleanup a bit the code
baseaggregator: Add a test where we add/remove source many times in a row
Wakeup pad before releasink it avoiding deadlocks

+fix the release request test... forever passes
Sensibly simplify removing pad test
Properly use the pad->activate_mode function to activate/desactivate our pads
Ensure we can not request pads while ->aggregate is called
Do not leak the buffer on removed pad
Revert "Ensure the buffer on a pad can not be consumed while we are inside ->aggregate()"

This reverts commit 9d917fe11fe3f7732888de51324a8731614c590a.
Revert "Ensure we can not request pads while ->aggregate is called"

This reverts commit ff1700c494390ef62aa67a4e60cf5f584187c79a.
We do not guarantee that there is a buffer on each pad when calling ->aggregate()
Try to cleanup debug log levels
Cleanup infinite seek implementation
Crappy way to send caps at the right time.

Useful for porting basemixer to finish_buffer.
Let's discuss that, hopefully things can happen with respect to:

https://bugzilla.gnome.org/show_bug.cgi?id=728138

Don't wanna code something clean if we can find a better solution
upper in the class hierarchy :)