P2P: Recover from successfully requested, but not started, listen

P2P: Recover from successfully requested, but not started, listen

It is possible for the start_listen() callback to be called to request
the driver to start a driver operation and stop_listen() called
immediately after that (e.g., due to a request to transmit a P2P Public
Action frame) before the driver has had time to start ROC and send an
event to notify of that. Such a sequence could result in
p2p->pending_listen_freq being left to a nonzero value without getting a
call to p2p_listen_cb() to clear it. This would stop an ongoing P2P
listen operation since no following p2p_listen() call would start the
listen due to the pending command being assumed to be in effect.

Fix this by detecting this particular sequence and clearing
p2p->pending_listen_freq.

This was found with the p2p_listen_and_offchannel_tx test case with the
new kernel scheduled and UML time-travel.

Signed-off-by: Jouni Malinen <j@w1.fi>