FT: Schedule wpa_ft_rrb_rx() through eloop in intra-process communication

With AP-AP communication, when hapd0 sends a packet, hapd1 can receive
it immediately and send a response. But hapd0 will only read and process
the response after it has returned from the sending context, that is
entered eloop again. So one does not need to consider the RX function of
the reply to run for the request sending hapd before the send calling
function has returned.

Previously, with intra-process communication, the packet is not
scheduled through eloop. Thus the RX handler of the reply might be run
while the sending context of the original request has not returned.
This might become problematic, e.g., when deferring a management frame
processing until an RRB response is received and then have the request
restarted and finished before the original request handling has been
stopped.

I'm not aware of any concrete bug this is currently triggering but came
across it while thinking of FT RRB AP-AP sequence numbering.

I think the non-eloop scheduling approach might be error-prone and thus
propose to model it more closely to the way the message would be
received from a socket. Additionally, this ensures that the tests model
AP-AP communication more closely to real world.

Solution: queue these packets through eloop.

Signed-off-by: Michael Braun <michael-dev@fami-braun.de>

src/ap/hostapd.h

@@ -185,6 +185,11 @@ struct hostapd_data {
 #endif /* CONFIG_FULL_DYNAMIC_VLAN */
 
 	struct l2_packet_data *l2;
+
+#ifdef CONFIG_IEEE80211R_AP
+	struct dl_list l2_queue;
+#endif /* CONFIG_IEEE80211R_AP */
+
 	struct wps_context *wps;
 
 	int beacon_set_done;