Fix message headers that weren't set in the http response headers.

[luankevinferreira]

Motivation:

Messages sent over the event bus can also contain headers. This can be specified by providing a DeliveryOptions when sending or publishing.

The following changes aim to fix the following problems in this flow:

• DeliveryOptions headers are not being set in the HTTP responses for message replies;
• Multi-value headers (like Set-Cookie) are not being set in the HTTP responses because it's not retrieving all the key values from the MultiMap;

[tsegismont]

Thanks for reporting this @luankevinferreira

Indeed, multi-value headers should be supported, can you add a test for it?

Nevertheless, I'm not convinced response message headers should be copied to the http response, because they can be defined in the ServiceResponse object.

[luankevinferreira]

Nevertheless, I'm not convinced response message headers should be copied to the http response, because they can be defined in the ServiceResponse object.

The problem with ServiceResponse is that JSON objects don't allow duplicated keys, which adds the limitation of having multiple headers like Set-Cookie, and since JSON is a convention to be used along with event bus like mentioned in the documentation, it would be required to be set by another way like the DeliveryOptions

See: https://vertx.io/docs/vertx-core/java/#_types_of_messages

[tsegismont]

Thank you for the updates

[tsegismont]

The problem with ServiceResponse is that JSON objects don't allow duplicated keys

That's right, thank you for spotting this. Then I think that we should store headers in the service response in the form of an array of json objects like this:

{
  "headers": [
    { "header1": "value1"},
    { "header1": "value2"},
    { "header2": "value3"},
  ]
}

And for backward compatibility, perhaps we can have a sysprop that switches between the old and the new format