rtspsrc: possible stack overrun in gst_rtsp_src_receive_response

For TCP interleaved streaming, the response to an RTSP message may be returned behind an arbitrarily long queue of TCP packets. In earlier releases, the receive loop was performed via goto, so that it would handle any number of incoming non-response messages while waiting for an expected response. But as of commit 81217528, that loop was re-implemented to use recursion. As a result, a large enough number of incoming data packets between a command and response will cause a stack overflow and crash the app.

(My application ran into this after upgrading to 1.16.2, while trying to play from a poorly implemented RTSP server that didn't do a good job of flushing its output queue in response to new RTSP PLAY (seek) requests. But this is generally problematic for servers implementing the ONVIF rate-control=no feature, where client-side flow control could block the TCP stream, causing the server to buffer a lot of outgoing data.)