Unify error message structure in EventBusBridge

[EmadAlblueshi]

Motivation:

The message structure should be consistent to all error messages in EventBusBridge. The following is a list of a consistent error types with descriptive messages:

Type : INVALID_JSON
Message : Malformed JSON

Type : MISSING_TYPE
Message : Message type is missing

Type : INVALID_TYPE 
Message : Invalid message type

Type : MISSING_ADDRESS
Message : Message address is missing

Type : REJECTED
Message : Message is rejected

Type : HANDLERS_MAX_LIMIT
Message : Registration handlers exceed maximum limit

Type : ADDRESS_MAX_LENGTH
Message : Address exceeds maximum length

Type ADDRESS_ALREADY_REGISTERED
Message : Address is already registered

Type ADDRESS_REGISTRATION
Message : Address registration is failed

Type : ACCESS_DENIED
Message : Address access is denied

Type : INVALID_REPLY_ADDRESS
Message : Reply address is invalid

Type : AUTHZ
Message : Authorization failed

Type : AUTHN
Message Authentication is required

Type SOCKET_EXCEPTION
Message : A socket exception occurred while attempting to establish or maintain a network connection

The failureCode for the above is -1 and all types with messages are tested except for SOCKET_EXCEPTION which I didn't find any unit test for such a use case so I added generic descriptive message in case the Throwable#getMessage() is null.

Finally, this PR addresses inconsistency of all error messages in EventBusBridge #2693

Thanks!

[EmadAlblueshi]

Ping @tsegismont :)

[EmadAlblueshi]

Regarding the behavior of the EventBusBridge, error message types should be categorized after reporting to determine whether to maintain the connection or close it immediately.

The primary objective is to minimize any potential attempts to exploit connection resources or expose security vulnerabilities.

For example, if the message is invalid or the authentication is required why we should keep the connection maintained?

At present, I believe it is necessary to improve the behavior of the EventBusBridge to address those edge cases more effectively.

I’m happy to know and learn more from you! @tsegismont @vietj