Allow MQTT topic to have wildcards (# or +)

[EricDuminil]

⚠️⚠️⚠️ Since we do not accept all types of pull requests and do not want to waste your time. Please be sure that you have read pull request rules:
https://github.com/louislam/uptime-kuma/blob/master/CONTRIBUTING.md#can-i-create-a-pull-request-for-uptime-kuma

Tick the checkbox if you understand [x]:

• I have read and understand the pull request rules.

Description

Fixes #1669 : MQTT topic couldn't contain any wildcard, due to a too restrictive check.
If a message was received, it means the topic was correct, which means no further check is required.

The change is small enough that I took the liberty to not start a discussion first.

Type of change

• Bug fix (non-breaking change which fixes an issue)

Checklist

• My code follows the style guidelines of this project
• I ran ESLint and other linters for modified files
• I have performed a self-review of my own code and tested it
• I have commented my code, particularly in hard-to-understand areas (including JSDoc for methods)
• My changes generates no new warnings
• My code needed automated testing. I have added them (this is optional task)

Screenshots (if any)

Please do not use any external image service. Instead, just paste in or drag and drop the image here, and it will be uploaded automatically.

[CommanderStorm]

Looks reasonable.
I have added one question below where I am a bit confused.

I have not looked into if this is a v2.0 (Bugfix of something in the beta) or v2.1 (new feature) PR

[CommanderStorm]

What is the background behind this change? How was 4 chosen? 🤔

[EricDuminil]

I almost doubled the number of tests in this describe. For each test, a HiveMQ docker container is started. With concurrency: true, they are all started at the same time.

My powerful laptop and servers didn't like too much starting 13 containers at exactly the same time. The test suite needed over 2 minutes, and sometimes didn't even return at all. With concurrency: 4, the suite consistently required ~22s, which cannot get much better with a 20s timeout. There are 3 timeout tests, so concurrency: 3 would probably be fine as well. Anything more than 4 and I'd be afraid to DDOS other computers when testing.

[EricDuminil]

I have not looked into if this is a v2.0 (Bugfix of something in the beta) or v2.1 (new feature) PR

As you wish. Since the core of this bugfix is basically just removing one if (messageTopic === topic), it might be interesting to fix it in the 1.23 branch too.

[CommanderStorm]

LGTM, thanks.
I am treating this as a feature
=> putting it into the v2.1 release window.

[lupaulus]

Solved by #6043 if merged @CommanderStorm @EricDuminil

[CommanderStorm]

Thanks for pointing out that they conflict.

@lupaulus @EricDuminil So which of the two should we keep?

[lupaulus]

@EricDuminil @CommanderStorm Mine is ready, here they are conflicts, it need to be adapted.

As for me, as long it works, it is ok. But it need to be added for 2.0.0 milestone

[CommanderStorm]

Neither will be added to the v2.0 milestone, sorry.
:main is feature frozen, only high severity bugs go in at this point

Once we have released the milestone, we can start adding features again

[EricDuminil]

@CommanderStorm @lupaulus The notification conflicts seem to come from unrelated commits which have been added to my PR. Sorry, I don't know anything about them.

My original commits can be seen at master...EricDuminil:uptime-kuma:275ab89e62

The tests are important IMHO, and try to send MQTT messages to both valid and invalid topics, with corresponding assertions.

As for the code itself: I don't think regexen are needed at all. If client.on("message") is called, the MQTT library already checked that the topic matches. The simplest fix is to simply remove if (messageTopic === topic).

[EricDuminil]

@CommanderStorm Should I rebase this PR?