Addressing Potential Memory Leak Issue in ZMQ Connection Handling

[ryan961]

• [x] The issue is present in the latest release.
• [x] I have searched the issues of this repository and believe that this is not a duplicate.

What happened?

While packaging ZMQ connections in the project to ensure high availability, the code uses dialEventSockLoop for constant proactive reconnection to ZMQ, which usually doesn't cause any issues. However, if ZMQ disconnects during operation, and then we try to close the process, the goroutine becomes stuck here,

https://github.com/chirpstack/chirpstack-gateway-bridge/blob/dfbaf37b022d7eeabde870fe2b8d8a465aca00b9/internal/backend/concentratord/concentratord.go#L109-L113

continuously trying to reconnect, hence preventing the process from exiting. It may be necessary to introduce an exit channel here to monitor the exit signals from the main program, thereby facilitating a smooth exit of the goroutine. Moreover, it seems that the zmq package has some configurations like zmq4.WithAutomaticReconnect and zmq4.WithDialerMaxRetries... Would it be unnecessary, then, to attempt reconnections manually here?

[brocaar]

Instead of fixing this, maybe it is better to remove ZMQ support altogether. The MQTT Forwarder has been out already quite some time and has been recommended since then over installing the GW Bridge on gateways.

Recommendations:

• On the gateway: MQTT Forwarder (accepting ZMQ + UDP)
• On the server: GW Bridge (accepting UDP + Basics Station)