Issue #168/string keys for consumer message headers

[ColinDKelley]

Addresses issue #168:

• Change Headers to return Hash<String, String> as documented, starting with corresponding spec change.
• Rdoc updates.

These simplifications are also included:

• Change Headers to a Module since it is only a namespace and not a Class.
• Use __dir__ for the directory of the current __FILE__.

Note: this is a breaking change since any code that is reading the headers today with symbols will need to change to strings. Because the version number starts with 0., Sem Ver doesn't require a major version bump. But we should advertise it broadly and at least do a minor version bump.

[ColinDKelley]

@thijsc

• I fixed that spec. https://github.com/appsignal/rdkafka-ruby/pull/207/commits/97e512243f05f9071c64d5c8502deff987551e72
• Also, I added a spec for Headers since that was missing: https://github.com/appsignal/rdkafka-ruby/pull/207/commits/0891e4d3d7c6db4d319a275613d378dcbf5c9f06
• And I was getting really nervous about breaking callers who might still expect Symbol keys. So I tried this pattern that we've had good luck with at our company: it raises an ArgumentError if any calling code makes the mistake of accessing the headers hash with a non-Symbol key. It's sort of the opposite of ActiveSupport::HashWIthIndifferentAccess. :) And also I froze the headers so that callers can't mutate them and possibly mess up this contract. What do you think?https://github.com/appsignal/rdkafka-ruby/pull/207/commits/bfc9eaf763d52abb6e10bea243c67b39afd66fb9

[ColinDKelley]

@thijsc Here's a possible interim approach on Symbol-vs-String that is pretty close to ActiveSupport::HashWithIndifferentAccess but it's inline/dependency-free. It will tolerate a Symbol key (by converting it to String) but it also emits a Kern.warn deprecation warning in that case. This will give developers some notice and a bit of time to switch over without breaking anything. (It documents that when version 1 ships, any code that is still using Symbols will break.) https://github.com/appsignal/rdkafka-ruby/pull/207/commits/ef94f01476553f94f2207706180a6c33c47d0351

[ColinDKelley]

@thijsc Just following up to see if you have any thoughts on the above?

[thijsc]

I think having backwards compatibility for a while would be nice.

[thijsc]

Could you rebase on main? A fix was merged that will hopefully lead to a green build for this.

[ColinDKelley]

@thijsc Will do.

[ColinDKelley]

@thijsc The build here is green after the rebase. 👍

[thijsc]

Thanks!

[mensfeld]

@thijsc there is one problem with this PR. Previous headers were not frozen. While it's not a big deal I want to point out, that this is an API change.

ref https://github.com/karafka/karafka/pull/1057/files#diff-6bd2419c5896e14516e5e87d63feb25a856c29f1670f4c85d2ef48bf11feba80L16