Provide ability to publish and consume binary data directly

[laserg]

CASE:
OutboundMessage#msg is a String,
In this way, it forces us to use marshalling (XML, JSON, YML) insted of serialization (CBOR, protobuf)
In the case of converting a binary array to we at least lose time. In addition, the string representation of the binary array will weigh twice as much since char = 16 bit vs byte = 8 bit

For instance you can compare implementtion of methods dump and dumps in kotlinx/serialization/SerialImplicits.kt kotlinx-serialization-runtime-0.11.1

[laserg]

Another bad thing I discovered is that your API is non-consistent in terms of data types.
As I already said OutboundMessage#msg is a String, Not so bad on its own.
But in com.viartemev.thewhiterabbit.consumer.ConfirmConsumer all methods use the following lambda (com.rabbitmq.client.Delivery) -> kotlin.Unit
And com.rabbitmq.client.Delivery#_body is a byte[]

So we publish the String and consume byte[]
CASE1: if we publish JSON (for i.e.) we consume byte representation of JSON (looks simple)
CASE2: if we publish CBOR first of all we encode it as string and we consume byte representation of what we encode.
Now it our object that was bynary encoded then represenrted as string and this string represented as byte array (looks hard)

[laserg]

The PR with fix is #268
it was based on v.0.0.5 as the master branch is not in production-ready state

For master com.viartemev.thewhiterabbit.channel.TxChannel.Transaction line 37 fix needed.

[viartemev]

@laserg thank you for contribution.
I totally agree with you, that OutboundMessage should have ByteArray instead of String. As a part of work on RPC implementation, I added a new RabbitMqMessage type which has only basic properties and body.
In the future, all methods of the library should operate with this type. Feel free to contribute.

[laserg]

Give me a couple of minutes. I will fix PR.

[viartemev]

@laserg Moving to new RabbitMqMessage type required adding Envelop field to this type also

[viartemev]

@laserg I agree with you about inconsistency. But this problem should be solved in another issue. Before that, all required parameters should be collected and after we can move to one general type.

[laserg]

@viartemev Yep. Now #268
Contains backward compatible API fix,

[viartemev]

This feature available in version 0.0.6

[laserg]

@viartemev, please do not forget to close this issue.
Thank you for fast release.