Depreciate Publish Subscribe Server

[Eric-Edlund]

Having a module handle message distribution creates architecture problems:

• Doing so requires the pub/sub module lie about it's identity when sending messages, something that I've spent the last few months trying to prevent modules from doing.
• By composing messages, enforcing a maximum message size becomes weird. That, or the pub/sub server only can distribute messages of a certain length (also weird).
• Now that Modules need to explicitly declare what message types they can receive, and the message system and SPARK will ensure a level of message safety. The pub/sub module subverts this by wrapping distributed messages in a Publish_Result message, meaning modules which rely on pub/sub get no guarantees about what message types they're given.
• Due to module's asynchronous nature, (it appears) there is no way to coordinate the timing of subscribing and publishing to a channel, meaning that a module could subscribe to a channel immediately and still have missed several messages already published due to thread timing.

These problems, along with the Status parameter of the pub/sub messages colliding with the message system's Status, prevent Pub/sub from using a Mercury generated API. The message guarantees that apply to all other modules don't apply to pub/sub, a sign that maybe pub/sub isn't really a module.

Pub/Sub functionality should be moved into the message manager or another core component of CubedOS parallel to it. This would allow us to coordinate registering and subscribing to channels with native Ada async methods and better enforce message type safety.

If we decide to leave pub/sub as a module and want an auto-generated API, rename Status to something else in the MXDR file. Most of the auto-generated procedures won't be usable, but it should work.

[pchapin]

Some sort of support for the publish/subscribe paradigm is essential since it is heavily used by CFS. I anticipate CFS users who want to try CubedOS will require support for this communication model. Many of the comments in the ticket pertain to the v2 architecture and may or may not be an issue for the v1 architecture (depending on how it evolves). The issue requires further discussion.