souphttpsrc: fix possible data corruption after seeking

souphttpsrc: fix possible data corruption after seeking

Consider a downstream element that may issue seeks in very short
succession (e.g. queue2), depending on the access pattern of
the downstream element (e.g. qtdemux with audio/video chunks
interleaved so that there's always a sizeable gap between the
current chunks for each stream). In this case, queue2 will maintain
two ranges, and even when it serves a chunk from memory, it will
switch ranges and make souphttpsrc seek to the end of the available
data for that range, assuming that that's where we'll want to
continue reading from next.

This may lead to the following seek request pattern:

 - source reading position A
 - seek to B
 - now reading position still A, requested_postion is B
 - streaming thread to be restarted to continue from B
 - seek to A, before streaming thread had time to do the seek
 - do_seek() now sees reading position == seek position and
   returns early.
 - however, requested position is still B from the earlier
   seek request
 - streaming thread starts up, sees that a seek to B is pending
   and requests data from B from the server, while the GstBaseSrc
   segment has of course been updated/reset to position A, which
   was the last seek request.
 - we will now send data for position B and pretend that's the
   data from position A (via the newsegment event, etc.)
 - this causes data corruption

Reproducible doing seek-emulated fast-forward/backward on 006648.