MQTT subscription

[timcowlishaw]

Addresses #355, allowing us to scale the mqtt task through parallel processing. We have two named "main" subscribers which ensure that messages are not dropped in the event of downtime (they have consistent client ids and persistent sessions), and a secondary subscriber role (with transient ids and clean sessions) which can be scaled with load. Needs thorough testing on staging before deployment!

⚠️ on deployment, we need to: ⚠️

• bring down the app entirely, including the old mqtt-task
• delete the old "mqtt subscriber" client in emqx, so that no messages are retained for it, as the client id changes in this release
• run migrations BEFORE bringing up the mqtt-task again, as otherwise duplicate components will be created
• bring up the entire stack again

[timcowlishaw]

(deployed to staging on branch staging-2024-01-01, although it was actually deployed on the 25th of sept, sorry for the confusion)

[timcowlishaw]

#TODO: ensure that mqtt-task gets an exclusive lock on the components table before creating a component - it only happens in "unrealistic" testing conditions currently, but it is possible for two identical components to be created at once