Solution: applied clang-format

Solution: replace by "routing id"

mechanisms

Solution: uniformly require a ZAP domain to be set to activate ZAP
handling, clarify comment on Stonehouse pattern

Solution: replace by "routing id"

Problem: no tests for client-side events for successful handshake and authentication failure in handshake

Solution: added tests for CURVE, add emitting of client-side event in curve_client_t; add ZAP code 300/500 tests for all mechanisms; suppress sending an error message for ZAP code 300

Solution: use check_basic_command_structure in curve_client_t::decode, also prepare other client mechanisms to use that method by rearranging inheritance hierarchy

Solution: emit socket monitor events for PLAIN protocol errors (like CURVE)

Solution: redesign ZMQ_HANDSHAKE_FAILED_* events, introduce new class of ZMQ_HANDSHAKE_FAILED_AUTH events

Solution: replaced unreachable code by assertions and adapted uses

Solution: move relevant behavior to zap_client_t

Solution: unification, pulled up common behaviour to zap_client_t/zap_client_common_handshake_t

Problem: zap_msg_available duplicated between curve_server_t and plain_server_t (with deviating behaviour)

Solution: pull up into zap_client_common_handshake_t, along with handle_zap_status_code and error_detail/current_error_detail

Solution: extract into new intermediate base class zap_client_common_handshake_t

Solution: extract receive_and_process_zap_reply into zap_client_t and convert zap_client_t into base class of the server mechanism classes

Solution: Use zap_client_t::send_zap_request

Solution: Set more flag depending on presence of credentials

Problem: null_mechanism duplicates zap_client_t::send_zap_request\nSolution: use zap_client_t::send_zap_request

Solution: created a zap_client_t class, extracted first function send_zap_request from curve_server_t