Bluetooth: Host: Move tx_processor to bt_taskq

It's not safe for the tx_processor to share the system workqueue with
work items that block the thread until tx_processor runs. This is a
deadlock.

The Bluetooth Host itself performs these operations, usually involving
bt_hci_cmd_alloc(), on the system workqueue.

This change effectively gives tx_processor its own thread, like the BT
TX thread that used to exist. But, this time the thread is intended to
be shared with any other non-blocking Bluetooth Host tasks.

The bt_taskq rules tx_processor is supposed to be non-blocking and only
have code under our control on the thread stack. Unfortunately, this is
not entirely true currently. But we consider it close enough for now and
will ensure it starts adhering to the rules in the future. Examples of
problems:

 - The tx_processor invokes bt_hci_send(), driver code which has no
   rules limiting what it can do on our thread.
 - The tx_processor invokes net_buf_unref() on stack-external net_buf
   which executes user code on our thread.

Signed-off-by: Aleksander Wasaznik <[email protected]>

Author: alwa-nordic

subsys/bluetooth/host/hci_core.c

@@ -48,6 +48,7 @@
 
 #include "addr_internal.h"
 #include "adv.h"
+#include "bt_taskq.h"
 #include "common/hci_common_internal.h"
 #include "common/bt_str.h"
 #include "common/rpa.h"
@@ -5037,5 +5038,5 @@ static K_WORK_DEFINE(tx_work, tx_processor);
 void bt_tx_irq_raise(void)
 {
 	LOG_DBG("kick TX");
-	k_work_submit(&tx_work);
+	k_work_submit_to_queue(bt_taskq_chosen, &tx_work);
 }