feat: smart detection of bridged messages so messages don't loop back

[h3nill]

trafficstars

[mnpw]

Design change suggestion: BridgeLink should forward data instead of receiving data.

What

BrideLink should play the role of sending messages (publishing) to an external broker rather than receiving messages (subscribing) from an external broker.

Why

It is likely to have a scenario where rumqttd is required to bridge message to another broker. It is less likely to have a scenario where rumqttd is required to bridge messages from another broker. So in the former case we cannot set up bridging with BrideLink playing the role of receiving messages.

To elaborate on this, suppose following is the desired setup: rumqttd >------> Customer_broker (mosquitto/hivemq/something_else)

>--- denotes sending end ---> denotes receiving end

We cannot introduce a BridgeLink that receives messages because we don't control how the Customer_broker behaves. We can only configure rumqttd.

How

Let us say we have following configuration: A >------> b-B >------> c-C

A, B, and C denote MQTT brokers a, b and c denote BridgeLinks

Currently following happens:

1. b connects to A
2. b subscribes to a topic on A
3. A forwards messages to b
4. b forwards the messages to B

We should instead have following configuration: A-a >------> B-b >------> C

With this, following should happen:

1. a connects to B
2. a subscribes to a topic on A
3. A forwards messages to a
4. a forwards messages to B

To achieve the new configuration, we can do something like this:

# config becomes:

[bridgelink]
name = ..
addr = ..
# this is filter on which bridge link subscribes from internal router and forwards whatever it gets to router at running at addr 
filter = .. 
...

---

# bridgelink becomes:

# subscribe to internal router
# setup connection to external router
...
loop {
	let messages = internal_router.recv();
	external_router.send(messages);
}

[h3nill]

Design change suggestion: BridgeLink should forward data instead of receiving data.

We can have both pull and pushed based system (which is what mosquitto does see http://www.steves-internet-guide.com/mosquitto-bridge-configuration/).

To start with we decided to implement the pulling part. Because the primary usecase for us is to create data redundancy. And for that configuring N brokers to pull data from 1 broker would be easier than configuring 1 broker to send to N brokers.

And in the case where we don't control the central broker it would be harder to create redundancy with push based system, we we cannot easy configure central broker to send data to other brokers.

In future we can add push based system as well.