usb: dwc3: gadget: Handle race between remove_request & ep_dequeue

Consider a case where remove_request from ep_disable & ep_dequeue
from function driver got called at the same time. In this case
due to release the spinlock at the time of giveback we would end up
mixing the execution of both the processes and would interfere in the
list operations.
Consider the following example:

remove_request
	|
	|
	V
STARTED_LIST
	|
	|
	V
	gadget_giveback
	(release_lock)			ep_dequeue
					(acquired_lock)
						|
						|
						V
					STARTED_LIST
						|
						|
						V
					move_cancelled_list
						|
						|
						V
						gadget_giveback
						(release_lock)
(acquired_lock)
rest of the started list empty
CANCELLED_LIST
	|
	|
	V
	gadget_giveback
	(release_lock)
						(acquired_lock)
						gadget_giveback
						[KERNEL_PANIC]

This is beause the cleanup_cancelled_request uses
list_for_each_entry_safe which caches the next node of the list
in a temp variable. Now when the lock is release the remove_request
process will free up that request. But the pointer was not updated
for cancelled_request. So the next time is acquired the lock it will
access a stray pointer which will lead to kernel panic.

Fix this by ensuring that when remove_request is called, ep_dequeue
does not execute cleanup_cancelled_request. The stop active transfer
from remove_request will clear the transfer started flag therefore
make sure ep_dequeue cleanup_cancelled_request executed only when
the flag is set along the transfer pending bit. Additionally
adding check in stop_active_transfer,if ep cmd failure with
-ETIMEDOUT is seen then don't modify the flags at all.

Change-Id: If17c2901e572d071808c2e71ff2d9476ce56c30d
Signed-off-by: Udipto Goswami <ugoswami@codeaurora.org>