First implementation of minimal Broker API

1. Agreed in the sense of you'll separate this into multiple classes (now or in a (near) future sprint)? Or as in "would be nice to have but I'll leave it at that"?

2. Well, we've a couple applications here that demonstrate the contrary quite vividly. You can perfectly just receive stuff and be done with it. A handler pattern always implements some kind of routing. And that routing might be message/content dependent. I don't see any disadvantage in having an extra router class (or several of them) which does just that. In addition, if any patterns turn out to be prevalent macro objects are an option as stated above.

3. Technically, there're obviously extra pointers that you carry when you don't need parts of the functionality. Obviously, these are negligible for any reasonable connection count. From the conceptual point of view, though, the argument is about keeping the interface clean and the mental overhead for the API user small; quite frankly, a class that has just one public method is arguably easier to use - and harder to mis-use for that matter - than one that has a dozen. So this is about expressing usage intent.