Can't create subscriber on ESP32-C3

Nobody has claimed this yet.

#### Problem description
I have recently started to experiment with micro-ROS. While the examples involving just publishers such as [`int32_publisher`](https://github.com/micro-ROS/micro_ros_espidf_component/tree/humble/examples/int32_publisher) are running fine, if I run any example involving a **subscriber** such as [`int32_sub_pub`](https://github.com/micro-ROS/micro_ros_espidf_component/tree/humble/examples/int32_sub_pub) or [`ping_pong`](https://github.com/micro-ROS/micro_ros_espidf_component/tree/humble/examples/ping_pong) according to the official documentation using the provided **Dockerfile** this results in a **stack dump**.

- Hardware description: [Seeed Studio Xiao ESP32C3](https://www.seeedstudio.com/Seeed-XIAO-ESP32C3-p-5431.html)/[ESP32-C3-MINI-1](https://www.ebay.co.uk/itm/355174946337?var=624409881517)
- RTOS: FreeRTOS
- Installation type: `micro_ros_espidf_component`
- Version or commit hash: humble (27158f2369bd7bd02ce3cda61a785bf32ce10883)

#### Steps to reproduce the issue
In order to replicate this flash the ESP32-C3 board with one of the examples involving a subscriber (in the following I will make use of [`int32_sub_pub`](https://github.com/micro-ROS/micro_ros_espidf_component/tree/humble/examples/int32_sub_pub)). In my case I open it in the container with the provided Dockerfile in interactive mode:
```bash
$ export LC_ALL=C # Override locale settings
$ . $IDF_PATH/export.sh
$ cd examples/int32_sub_pub
$ idf.py set-target esp32c3
$ idf.py menuconfig
# Set micro-ROS agent Settings ->
# WiFi configuration ->
# WiFI SSID (test_hotspot)
# WiFI Password (test_password)
# micro-ROS Agent IP (10.42.0.1)
$ idf.py build
$ sudo chmod o+rw /dev/ttyACM0 # Allow to write to device file
$ idf.py flash
```
connect both micro-controller and computer to the same hotspot, in my case a self-hosted hotspot, then run the micro-ROS agent on the computer (`10.42.0.1`)
```bash
$ docker run -it --rm --net=host microros/micro-ros-agent:humble udp4 --port 8888 -v6
```
and finally monitor the ESP32-C3 with:
```bash
$ idf.py monitor
```

#### Expected behavior
The ESP-C3 should publish its messages to the micro-ROS agent on the `int32_publisher` topic and wait for messages on the `int32_subscriber` topic. I should be able to see both topics on the micro-ROS agent side.

#### Actual behavior
The ESP32-C3 runs into a **stack dump and reboots** (For a full output see [subscriber_bug.txt](https://github.com/micro-ROS/micro_ros_espidf_component/files/13629494/subscriber_bug.txt)):
```bash
I (1599) main_task: Returned from app_main()
Guru Meditation Error: Core 0 panic'ed (Illegal instruction). Exception was unhandled.

Stack dump detected
Core 0 register dump:
MEPC : 0x42015a2e RA : 0x4201596c SP : 0x3fcad780 GP : 0x3fc91400
0x42015a2e: rmw_wait at ??:?

0x4201596c: rmw_wait at ??:?

TP : 0x3fc901b8 T0 : 0x4005890e T1 : 0x0000000c T2 : 0x00068081
S0/FP : 0x3fc94350 S1 : 0x3fcadafc A0 : 0x3fca9a58 A1 : 0x00001000
A2 : 0x00001000 A3 : 0x00000001 A4 : 0xffffffff A5 : 0x00000001
A6 : 0x00000000 A7 : 0xf4240000 S2 : 0x3fcadaf0 S3 : 0x00000064
S4 : 0x3fcadb08 S5 : 0x3fcadb14 S6 : 0x05f5e100 S7 : 0x00000000
S8 : 0x00000000 S9 : 0x3fcad8c4 S10 : 0x3fcadaec S11 : 0x00000000
T3 : 0x00000975 T4 : 0x00000000 T5 : 0x4200a2c8 T6 : 0x4200a2d0
0x4200a2c8: __default_deallocate at allocator.c:?

0x4200a2d0: __default_allocate at allocator.c:?

MSTATUS : 0x00001881 MTVEC : 0x40380001 MCAUSE : 0x00000002 MTVAL : 0xd009f7d3
0x40380001: _vector_table at ??:?

MHARTID : 0x00000000

Backtrace:

0x42015a2e in rmw_wait ()
#0 0x42015a2e in rmw_wait ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
ELF file SHA256: dc5c59390d980376
Rebooting...
```

#### Additional information
I have tried the following already to no avail, the problem stays the very same:
- Reflash the ESP32 several times
- Try a different ESP32 I had lying around
- Change hotspot
- Switch to ROS 2 Iron instead of Humble
- Remove the publisher, being left with an example with only a subscriber
- [Doubled the statically allocated memory to 32000 Bytes for the ROS task](https://github.com/micro-ROS/micro_ros_setup/issues/526#issuecomment-1139360309) in `$ idf.py menuconfig` under `micro-ROS example-app settings/Stack the micro-ROS app (Bytes)`
- Added the following options to `colcon.meta` and proceed with a clean build, cleaning the workspace first with `$ idf.py clean-microros`:
- Added [`-DRMW_UXRCE_ALLOW_DYNAMIC_ALLOCATIONS=ON` to `microxrcedds_client.cmake-args`](https://github.com/micro-ROS/micro_ros_setup/issues/526#issuecomment-1139334773)
- Increased the number of nodes `-DRMW_UXRCE_MAX_NODES`, publishers `-DRMW_UXRCE_MAX_PUBLISHERS`, subscribers `-DRMW_UXRCE_MAX_SUBSCRIPTIONS`, guard conditions `-DRMW_UXRCE_MAX_GUARD_CONDITION` under `rmw_microxrcedds.cmake-args`

If I comment the line that adds the subscription to the executor, e.g. `RCCHECK(rclc_executor_add_subscription(&executor, &subscriber, &recv_msg, &subscription_callback, ON_NEW_DATA));` the publisher runs just fine while clearly the subscriber will not work.

Any input is highly appreciated!

Start with examples/int32_sub_pub and ping_pong, then trace subscription setup into rmw_wait shown in the monitor backtrace; compare with int32_publisher and inspect subscriber_bug.txt. Reproduce with the provided Dockerfile and ESP32-C3 steps. Done means a subscriber example runs without the panic and both expected topics are visible through the agent.

Written by the indexing model from the issue text.