aggregator: avoid race condition after FLUSH_STOP event

We wait until all pads have buffers in gst_aggregator_wait_and_check()but in case of FLUSH_STOP event first_buffer was not getting true which is one of the condition to wait in gst_aggregator_wait_and_check() causing fail to wait, Hence there is race condition between the gst_aggregator_aggregate_func, that runs in the task thread on the gstaggregator base class and function gst_aggregator_pad_chain_internal()(specific from Line number:3333 case GST_AGGREGATOR_START_TIME_SELECTION_FIRST: ), that run in the streaming thread of the input.

If the input sets the timestamp later then the gst_aggregator_aggregate_func starts proccessing (arrives to the gst_video_aggregator_aggregate), then the correct input timestamp is lost, and the output starts from the timestamp 0. This makes the compositors to postpone sending few first frames.

As a proposed solution we are making first_buffer = true in case of FLUSH_STOP and start-time-selection=first.

P.S. it's only related to the GST_AGGREGATOR_START_TIME_SELECTION_FIRST start time selection, because this setup means that we start the output segment with the timestamp of the first buffer.