rtspsrc: Don't allow commands to cancel handle-request

Handling of a server request is racy, and the connection can get flushed if the app sends a SET_PARAMETER request to the server while the handle-request signal handler is running. This will cause the response to never get sent out, and the server will have to timeout even though it successfully sent the request to us.

This is because gst_rtspsrc_loop_send_cmd() first cancels the currently-pending command, then checks src->busy_cmd to check whether it is allowed to flush the connection and interrupt the currently-running command, but we don't update that when handling a request, so the connection gets flushed.

We also cannot update src->busy_cmd for handle_request because that can only be safely written to from one location: gst_rtspsrc_thread() inside src->task, which is thread-safe due to how gst_task_start() works.

Reads are thread-safe due to the object lock, but writes from multiple threads aren't thread-safe even with the object lock because the command specified in busy_cmd is not executed with the object lock held, so we'd need to hold the object lock while executing handle_request, and we might as well not update busy_cmd at all.