ESP32 Crash with Many MQTT Messages

### The problem

If many MQTT messages are received in a short time frame, the board panics and restarts.

### Which version of ESPHome has the issue?

2022.1.0-dev

### What type of installation are you using?

pip

### Which version of Home Assistant has the issue?

_No response_

### What platform are you using?

ESP32

### Board

mhetesp32devkit

### Component causing the issue

mqtt

### Example YAML snippet

```yaml
esphome:
name: q1
platform: ESP32
board: mhetesp32devkit
arduino_version: latest

wifi:
ssid: xxxxxxxx
password: xxxxxxxx
fast_connect: true

# web_server:
# port: 80

mqtt:
broker: 10.0.19.5
discovery: false

# Enable logging
logger:

ota:
password: xxxxxxxx

dallas:
- pin: 32

switch:
- platform: gpio
name: "status light"
pin: 2
inverted: True

output:
- platform: ledc
pin: 25
frequency: 19531Hz
id: LED_gpio_25

- platform: ledc
pin: 26
frequency: 19531Hz
id: LED_gpio_26

- platform: ledc
pin: 27
frequency: 19531Hz
id: LED_gpio_27

- platform: ledc
pin: 14
frequency: 19531Hz
id: LED_gpio_14

- platform: ledc
pin: 12
frequency: 19531Hz
id: LED_gpio_12

- platform: ledc
pin: 16
frequency: 19531Hz
id: LED_gpio_16

- platform: ledc
pin: 17
frequency: 19531Hz
id: LED_gpio_17

- platform: ledc
pin: 18
frequency: 19531Hz
id: LED_gpio_18

- platform: ledc
pin: 19
frequency: 19531Hz
id: LED_gpio_19

- platform: ledc
pin: 21
frequency: 19531Hz
id: LED_gpio_21

light:
# - platform: monochromatic
# name: "deca1"
# id: "deca1"
# default_transition_length: 2s
# output: LED_gpio_25

# - platform: monochromatic
# name: "deca2"
# default_transition_length: 2s
# output: LED_gpio_26

# - platform: monochromatic
# name: "deca3"
# default_transition_length: 2s
# output: LED_gpio_27

# - platform: monochromatic
# name: "deca4"
# default_transition_length: 2s
# output: LED_gpio_14

# - platform: monochromatic
# name: "deca5"
# default_transition_length: 2s
# output: LED_gpio_12

- platform: monochromatic
name: "deca6"
# rear right strip
id: "deca6"
default_transition_length: 2s
output: LED_gpio_16
effects:
- pulse:

- platform: monochromatic
name: "deca7"
# front left
id: "deca7"
default_transition_length: 2s
output: LED_gpio_17
effects:
- pulse:

- platform: monochromatic
name: "deca8"
# front right
id: "deca8"
default_transition_length: 2s
output: LED_gpio_18
effects:
- pulse:

- platform: monochromatic
name: "deca9"
# rear left
id: "deca9"
default_transition_length: 2s
output: LED_gpio_19
effects:
- pulse:

# - platform: monochromatic
# name: "deca10"
# default_transition_length: 2s
# output: LED_gpio_21

- platform: partition
name: "ceiling"
default_transition_length: 2s
effects:
- pulse:
segments:
- single_light_id: deca6
- single_light_id: deca7
- single_light_id: deca8
- single_light_id: deca9

sensor:
- platform: dallas
index: 0
name: "q1_quinled_deca temp"
- platform: uptime
name: Uptime
```

### Anything in the logs that might be useful for us?

```txt
[13:38:27]E (73208) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time:
[13:38:27]E (73208) task_wdt: - async_tcp (CPU 1)
[13:38:27]E (73208) task_wdt: Tasks currently running:
[13:38:27]E (73208) task_wdt: CPU 0: IDLE0
[13:38:27]E (73208) task_wdt: CPU 1: IDLE1
[13:38:27]E (73208) task_wdt: Aborting.
[13:38:27]abort() was called at PC 0x4014e224 on core 0
```
```

### Additional information

I am able to trigger this bug by sending a pile of MQTT commands to change brightness of the four connected channels. Seems to be much more difficult to trigger when using the partition to control all four simultaneously, which results in ¼ of the MQTT messages.

Log using latest release: [crnb60-esp32-exception1.log](https://github.com/esphome/issues/files/7739843/crnb60-esp32-exception1.log)
Log using dev branch: [crnb60-esp32-exception2-dev.log](https://github.com/esphome/issues/files/7739844/crnb60-esp32-exception2-dev.log)