Make the use of the protocol transport agnostic

[jmader]

There are some aspects of the code in the protocol subdirectory that have references to zmq from outside the subdirectory. The desire is for the zmq-specific aspects to be wholly contained within the protocol subdirectory; this will require establishing unique exceptions that can be caught in other mKTL code rather than relying on zmq exceptions.

[prkrtg]

To expand based on issue #19

mKTL currently uses ZeroMQ directly for message transport, and transport mechanics are tightly coupled to higher-level messaging behavior.

This coupling makes it difficult to:

• Introduce alternative transports (e.g. brokered messaging, raw TCP)
• Reuse protocol logic across different deployment models
• Swap or test transports independently

Proposed Change

Introduce a generic transport interface that abstracts message delivery mechanics from protocol semantics.
The transport interface should define operations such as:

• connect / disconnect
• send message envelope
• receive message envelope
• transport lifecycle and error signaling

The existing ZeroMQ-based implementation would become:

• A concrete transport adapter
• Fully compliant with the abstract transport interface

Benefits

• Enables alternative transports (brokered, embedded, test-only)
• Allows protocol logic to remain transport-independent
• Improves modularity and code clarity
• Reduces long-term coupling to ZeroMQ

Notes:

• No requirement to remove ZeroMQ
• No immediate support for additional transports required
• No changes to user-facing APIs in the initial step