feat: [SRE-517] create a consumer module

[btkostner]

This creates a Kafee.Consumer module that can take multiple different backends (similar to the producer.) This determines the whole backend process tree. Aside from that, the handle_message/1 and handle_failure/2 functions are generic and don't require any code changes based on the backend picked.

Kafee.Consumer.BroadwayBackend

This backend uses the Broadway library to process Kafka messages. It's made to be a freight train of maximum throughput that won't stop for anything. This is great for processing a ton of messages that require no order guarantee and have their own dead letter failure logic.

Kafee.Consumer.BrodBackend

This backend will use :brod directly. It will spin up a process for each partition to process messages, but will only process them one at a time. This means if a message fails to process, it will be retried and not committed. This sacrifices throughput for safer message handling and order guarantees.

nil

Because it's super annoying to try starting a service locally only for it to start throwing "I can't connect to Kafka" errors. By default the Kafee.Consumer module will have a nil backend and not start any tree. This makes it easier for development and testing.

Different approaches

This module goes a bit different that the producer in that I'm using NimbleOptions to parse and validate options given, and avoiding creating a Config module to hold everything. This should end up being cleaner code in the long term. If successful, I'll probably take a deeper look into the producer code and try to clean it up before 3.0 release.

I also took some inspiration from how Broadway handles start_link and __using__ to try and avoid huge macros and cleaner code. I think it's working out better.

[btkostner]

For those interested in seeing how it's actually used: here are two integration tests. Once for brod and one for broadway.

[btkostner]

Yet to do:

• Setup encoder decoder module with consumer
• Look into our Elixir watcher process we had to create last peak and see if we need to add that into Kafee This was due to Elsa, not the lower level brod library Kafee uses.
• Ensure docs are solid

Things outside this PR:

• Add request id to all outgoing Kafka messages
• Maybe some docs on error handling or ideas
• Maybe backport our configuration handling to the producer modules to clean code up
• Maybe standardize on a single message struct (instead of a producer message and a consumer message)

[doomspork]

I've looked through the code and everything looks good. Given we've discussed this quite a bit in Slack we should be good to go. Excited to try this out in one of the WMS services.