ESP32 crashes when listening_message_reliably

Nobody has claimed this yet.

## ESP32 crashes when listening_message_reliably

- Hardware description: ESP32 serially linked to a nRF5340DK (using UART1 on pins 19/18 as TX/RX)
- RTOS: FreeRTOS
- Installation type: micro_ros_espidf_component, ESP IDF v4.4
- Version or commit hash: humble

#### Steps to reproduce the issue
My project consist on controlling a BT Mesh provisioner via ROS, and transmitting sensors data from the Mesh network to ROS.
The ESP32 serves as a message bridge between the provisioner and ROS.
For that I've got 4 threads running :
- the uROS thread (priority 5, stack 16000 bytes) with 2 subs and 2 pubs
- an "uart_phy" thread (priority 6, stack 4096 bytes) which job is to read data from UART1 and sends it to uart_mac_rx with a message queue
- 2 "uart_mac_rx" and "uart_mac_tx" threads (priority 6, stack 4096 bytes). uart_mac_rx gets data from uart_phy and publishes message to ROS. uart_mac_tx receives messages from the subscribers callbacks and transmits data to UART1

The nRF5340 scans for unprovisioned ("unconnected") mesh nodes, and sends the UUIDs to the ESP32 via serial.
So the ESP32 receives a 16 bytes UUID from UART, the uart_phy sends this UUID to uart_mac_rx through a message queue.
uart_mac_rx wakes up because something is in the queue, sees that it is an UUID, and publish it with my "unprov_pub".
The ROS message is the following :
ble2ros_interfaces/msg/Beacon.msg
```
# Represent an unprovisioned beacon from BT Mesh
uint8[16] uuid
```

#### Expected behavior
UUIDs are sent to ROS without error

#### Actual behavior
Sometimes, mostly when the ESP32 receives a lot of UUID's to transmit to ROS, i got the following error :
`assert failed: pbuf_free IDF/components/lwip/lwip/src/core/pbuf.c:757 (pbuf_free: p->ref > 0)`
OR
`assert failed: tlsf_free heap_tlsf.c:872 (!block_is_free(block) && "block already marked as free")`

but mostly the pbuf_free assert failed.
The most frequent stack backtrace is the following :
```
assert failed: pbuf_free IDF/components/lwip/lwip/src/core/pbuf.c:757 (pbuf_free: p->ref > 0)

Backtrace:0x40081ade:0x3ffd0a700x400891bd:0x3ffd0a90 0x4008fd5d:0x3ffd0ab0 0x400f3de7:0x3ffd0bd0 0x401057c1:0x3ffd0bf0 0x400f03ef:0x3ffd0c10 0x400f0ff2:0x3ffd0c50 0x400f1072:0x3ffd0cb0 0x400de19d:0x3ffd0cd0 0x400ddfad:0x3ffd0d00 0x400dd2fc:0x3ffd0d30 0x400dd488:0x3ffd0dd0 0x400e2836:0x3ffd0df0 0x400e0e4b:0x3ffd0e40 0x400da51d:0x3ffd0eb0 0x400da563:0x3ffd0ef0 0x400d6e6c:0x3ffd0f10 0x400d6e7e:0x3ffd0f30 0x4008c37d:0x3ffd0f50
0x40081ade: panic_abort at /home/samy/esp/esp-idf/components/esp_system/panic.c:402
0x400891bd: esp_system_abort at /home/samy/esp/esp-idf/components/esp_system/esp_system.c:128
0x4008fd5d: __assert_func at /home/samy/esp/esp-idf/components/newlib/assert.c:85
0x400f3de7: pbuf_free at /home/samy/esp/esp-idf/components/lwip/lwip/src/core/pbuf.c:757 (discriminator 1)
0x401057c1: netbuf_delete at /home/samy/esp/esp-idf/components/lwip/lwip/src/api/netbuf.c:85
0x400f03ef: lwip_recvfrom_udp_raw at /home/samy/esp/esp-idf/components/lwip/lwip/src/api/sockets.c:1250
0x400f0ff2: lwip_recvfrom at /home/samy/esp/esp-idf/components/lwip/lwip/src/api/sockets.c:1292 (discriminator 4)
0x400f1072: lwip_recv at /home/samy/esp/esp-idf/components/lwip/lwip/src/api/sockets.c:1337
0x400de19d: uxr_read_udp_data_platform at ??:?
0x400ddfad: recv_udp_msg at udp_transport.c:?
0x400dd2fc: listen_message_reliably at session.c:?
0x400dd488: uxr_run_session_until_data at ??:?
0x400e2836: rmw_wait at ??:?
0x400e0e4b: rcl_wait at ??:?
0x400da51d: rclc_executor_spin_some$part$5 at executor.c:?
0x400da563: rclc_executor_spin_some at ??:?
0x400d6e6c: spin_uros at /home/samy/work/ble2ros/firmware/uros_node/main/uros/uros.c:119 (discriminator 1)
0x400d6e7e: uros_task at /home/samy/work/ble2ros/firmware/uros_node/main/uros/uros.c:126
0x4008c37d: vPortTaskWrapper at /home/samy/esp/esp-idf/components/freertos/port/xtensa/port.c:131
```

#### Additional information
I also had other configuration with at most 4 pubs and 4 subs, and this problem can occur with any publisher.
I went back to 2 pubs and 2 subs to get back to the basic uROS config (also resetted the max pub/sub in colcon.meta)

I looked if the heap became corrupted at some point, but it was always clean.

When disabling asserts, it stills crash with Guru meditation error: Core 0 panic'ed

I tried lowering priorities, (12 for UART, 11 for uROS), switching priorities (4 for UART, 5 for uROS), still got the same problem.

Looked over the internet for solutions, looked in this repo's issues, found nothing...

Looked if I had memory leaks, but found none

Start with the backtrace entry points uxr_read_udp_data_platform, recv_udp_msg, and listen_message_reliably, then reproduce the failure using the ESP-IDF 4.4 setup under high UUID traffic. Compare the pbuf_free and tlsf_free failures while checking the described UART, task, and publisher configuration. Done means the crash cause is isolated and the issue has a verified fix or workaround.

Written by the indexing model from the issue text.