queue: fix race when flush-stop event comes in whilst shutting down

Don't re-start the queue push task on the source pad when a
flush-stop event comes in and we're in the process of shutting
down, otherwise that task will never be stopped again.

When the element is set to READY state, the pads get de-activated.
The source pad gets deactivated before the queue's own activate_mode
function on the source pads gets called (which will stop the thread),
so checking whether the pad is active before re-starting the task on
receiving flush-stop should be fine. The problem would happen when the
flush-stop handler was called just after the queue's activate mode
function had stopped the task.

Spotted and debugged by Linus Svensson <linux.svensson@axis.com>

https://bugzilla.gnome.org/show_bug.cgi?id=734688
tests: add test that triggers deadlock in state change of queue

When receiving FLASH_STOP in a state transition to READY, a queue
element can end up with an active task that will never end.

https://bugzilla.gnome.org/show_bug.cgi?id=734688
pad: annotate GstPadEventFunction event with 'transfer full'

The callback is supposed to take ownership of the event so
best to be explicit about it.

https://bugzilla.gnome.org/show_bug.cgi?id=735210
pad: add g-i 'transfer full' annotations to chain and chain_list functions

https://bugzilla.gnome.org/show_bug.cgi?id=735210
concat: Allow seeking on the currently playing stream

This is consistent with the stream time reporting.
baseparse: handle streamheaders by prepending them to the stream

Add a first_buffer boolean state flag to have baseparse do actions
before pushing data. This is used to check the caps for streamheader
buffers that are prepended to the stream, but only if the first buffer
isn't already marked with the _HEADER flag. In this case, it is assumed
that the _HEADER marked buffer is the same as the streamheader.

https://bugzilla.gnome.org/show_bug.cgi?id=735070
bus: gst_bus_add_watch() can return 0 on error

Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=735195
buffer: do not touch memory tag flag when copying buffer flags

The tag memory flag will be set later if the memory is also copied. This
patch avoids buffers being freed needlessly in bufferpools.

https://bugzilla.gnome.org/show_bug.cgi?id=735574
manual: fix typo in advanced-dataaccess.xml

https://bugzilla.gnome.org/show_bug.cgi?id=735609
output-selector: Send all events to active src pad and EOS to all src pads

Fixes tests/icles/output-selector-test

https://bugzilla.gnome.org/show_bug.cgi?id=729811
pad: don't accept flush-stop on inactive pads

Inactive pads should at all times have the flushing flag set. This means
that when we get a flush-stop on an inactive pad we must ignore it.

On sinkpads, make this more explicit. We used to not clear the flush
flag but remove the events and then return an error because the flushing
flag was set. Now just simply refuse the event without doing anything.

On srcpads, check that we are trying to push a flush-stop event and
refuse it. We would allow this and mark the srcpad as non-flushing
anymore.

Fixes https://bugzilla.gnome.org/show_bug.cgi?id=735357
tests: add flush-stop on inactive pad test

Check that pushing flush-stop on an inactive pad does not clear the
flushing flag.
devicemonitor: fix typo in sample code in docs

https://bugzilla.gnome.org/show_bug.cgi?id=735975
baseparse: minor docs fix
valve: fix typo in description

https://bugzilla.gnome.org/show_bug.cgi?id=736455
query: add annotations to gst_query_set_nth_allocation_pool()

https://bugzilla.gnome.org//show_bug.cgi?id=736424
check: Adding documentation to the gst_check_setup_sink_pad_by_name function

https://bugzilla.gnome.org/show_bug.cgi?id=734190
pad: Make sure the buffer to get/pull_range() has at least the requested size

https://bugzilla.gnome.org/show_bug.cgi?id=735861
tools: gst-inspect: don't list pad functions

Don't print all the different pad functions, it's just
confusing and no one has ever needed to know this for
anything ever anyway, it's just useless information.
Besides, we also label the default implementations as
'custom' implementations (the code that tries to
prevent that doesn't actually work it seems).

https://bugzilla.gnome.org/show_bug.cgi?id=736377
check: Add a function to check destruction of objects

Add a method letting people to ensure that unreffing one object
leads to its destruction, and possibly the destruction of more object
(think destruction of a GstBin etc...).

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