Create/investigate secondary approach to sending final EOS on dsl_pipeline_stop

[rjhowell44]

First, sending a final EOS is required to ensure that the encode sinks - file, record, RTSP, etc. -- can terminate their stream correctly.
The current EOS method is to send a new EOS event to the Pipeline bin. The stop command is blocked while the EOS event travels inbound with the data buffers until it reaches the final Sink component(s). The stop command will unblock on final receipt of the EOS event, or on timeout. This works well for all tested cases except when using a URI Decode Source with an HTTP URI. The blocking times out first. The seems to be because of the amount of data that is buffered by the Source.

The alternative approach will be to send a series of events -- Flush-Start, Flush-Stop, and EOS -- to each of the Streammuxer's requested sink pads that are connected to a Source's src pad. The Source in each case will be set to a state of NULL first.

---

After investigation, it was found that new method works well for the HTTP URI Decode Source, but not as well for other Sources. Looking at the RTSP Source for example... the final EOS is always received, however, the RTSP Source reports an error trying to connect with the network when the Pipeline's state is set to NULL.

The plan is to go with the original approach for now, until more investigation can be done in the future.