Added headers to http credentials provider

[pranavr12]

Added headers to be sent as part of the request in the http credentials provider.
Added a couple of tests to check if the header is working is properly

[vagaerg]

It would be nice to have 2 extra test cases:

• A header value containing a colon (this should work based on your implementation), like Authorization: api-key:my-key
• A header value containing a comma (unsure how Airlift deals with this, we may need to escape the comma?)

[pranavr12]

I have added a test case for the first case. It works as expected.
With a comma, it becomes tricky since its a string. To support commas, we might have to take in the input as an actual array rather than a string. Should we address this ? Comma in a header value seems a bit off

[vagaerg]

The HTTP spec separates headers with \r\n so I don't think there's anything too strange about a comma on a header - the authorization header for SigV4 requests contains commas, for instance.

We can't easily make the config a native array as it's read from a text file, and looking at the Airlift config builder I don't think it supports escaping the commas.

We could read the config as a string and do the parsing ourselves. HTTP allows for all ASCII characters to be part of a header, but \r or \n cannot be used (since they separate different headers).

We could do something like

Splitter.on(",").trimResults().omitEmptyStrings().splitToStream(headerConfig.replaceAll(",,", "\r")).map(item -> item.replace("\r", ","))

This way if we want to have a comma as part of a header value, we need to double it (foo,,bar for header foo,bar).

[pranavr12]

Another potential solution - How about having another config like http.header.delimiter and we use this custom delimiter for spitting the header string. This gives the flexibility of having various kinds of delimiters. Ofcourse, the delimiter shouldn't be used in the header name or value

[vagaerg]

We could do that, but it feels like we are passing on the problem to the end users. A suggestion like the one above would work with any headers users want to provide

[pranavr12]

Just a thought - ,, Seems to be a bit unfriendly if ,, has to be used in the header value itself. Or, if the original value contains let's say value,,value, the configured value would be value,,,,value.
Instead, using a delimiter provides a flexibility of choosing something that they don't normally use in the headers. We can always have a default of ,. We can also use /r as the delimiter. WDYT ? I'm happy to change to your suggestion, though

[pranavr12]

Discussed that we'll be going ahead with @vagaerg 's approach of using ,, to represent commas in the header. Usage note will be added in the readme