Add document section for the internal EdgeX MessageBus

[lenny-goodell]

The current documentation doesn't have any sections that describe the internal EdgeX MessageBus.

Now that the internal EdgeX MessageBus has become more central to how EdgeX services communicate, we need a section dedicated to describing how works and how it is meant to be used. One key point that needs to be addressed is that it is meant to be internal to all the EdgeX services only. eKuiper is grandfathered in as an internal EdgeX Service.

[farshidtz]

Why should should the message bus component be internal to EdgeX?

I have nothing against preventing external access to EdgeX's internal communication but that doesn't mean we have to dedicate a message bus to each instance of EdgeX.

Most MQTT brokers can be setup as a multi tenant server, with clustering to scale out and advanced access control to prevent unauthorized access to topics. I can imagine an environment with one or more EdgeX instances and other servers but a single, highly scalable broker. Forcing the deployments have one broker per EdgeX instance adds deployment complexity and results in waste of resources.

[cloudxxx8]

We are not forcing users to use the default message bus settings, but that should be a reference deployment.
To consider the security matters, use a light weight internal message bus is easier to be controlled and secured.
Users can use their broker settings, but our concept here is still internal communication. It could avoid the topic conflict.

[farshidtz]

The pending ADR (#795) is indirectly forcing the users to dedicate a message bus to each instance of EdgeX, by hardcoding the topic prefix for Core Metadata (see #795 (comment)). You can see here that Core Data allows configuring the prefix.

As said, there are cases where it would be easier to share an instance of a message bus - please read my comment above. Just like it is easier in many cases to use an existing API Gateway or Secret Store.

A lightweight message bus will not be able to cope with high amount of data.

The topic conflict can be avoided by changing the prefixes.

[lenny-goodell]

addressed by #846