allow user provided metadata to override defaults

[dbhobbs]

Addresses #60

I have used this to override the default content-type: application/grpc+proto to successfully publish messages to Google Cloud PubSub.

I realize that this performs a map -> proplist -> map -> proplist conversion, but I didn't want to modify metadata_headers/1. If you want to change this approach I'm willing to do so and thanks for this project!

[tsloughter]

Thanks!

So the issue with using proplists:to_map is (at least in HTTP 1.1) there can be duplicate headers and the proper way to merge them into a single header is to concat the values with a comma. This would just drop all but 1 of the headers if they have duplicate keys.

Its been too long since I've looked at the HTTP2 spec, does the order of the headers matter? Could this just prepend the user supplied MD instead of appending? No merging necessary.

And could you add a test? Even if its just an eunit test in the module that tests that calling the function to get the headers returns the expected result (whether that ends up being an actual merger of the headers or a list with the extra metadata prepended to the beginning of the list).

[dbhobbs]

My first inclination was to just prepend the user supplied headers, so I'll give that a shot. My only concern is that prepend vs append relies on the encoding algorithm that hpack uses within chatterbox.

[dbhobbs]

Hmmm... prepending the user supplied doesn't work in this case. Google is failing the request and my process is receiving an unhandled message {:headers, 1, %{":status" => "400", "content-length" => "1555", "date" => "Thu, 11 Nov 2021 19:23:41 GMT", "referrer-policy" => "no-referrer"}}","timestamp":"2021-11-11T19:23:46.109Z"}. I assume that's due to duplicate content-type headers with different values. I'll take a crack at a different approach.

[dbhobbs]

I went on a journey of discovery and would like to clean up the commit history. Will reopen new PR after some more testing.