Separate env and kafka packages

[chris-martin]

We've discussed breaking up freckle-app but not in much concrete detail, so this may be more a proposal than necessarily a finished task. Often I find I just have to start working on something like this to figure out where the right splits are.

I think one fairly sure goal is to be able to stop installing Kafka on services that don't need it, so I took a look at how coupled our Kafka modules are to the rest of freckle-app and tried pulling it out into a freckle-kafka package. I guess it could depend on freckle-app, but I went a step further here and completely decoupled them so neither depends on the other.

Probably a separate repository would be warranted, but doing the refactor all in this repo is easy. Didn't give much thought to the package names, can change them to whatever folks prefer. Modules names could also be reconsidered.

The dependencies of the kafka code on the rest of freckle-app were:

• Freckle.App.Prelude - this was easily replaced by Relude.
• Freckle.App.Env - to write definitions for environment variable parsers; this includes our own Timeout type, which makes dropping down to the underlying envparse library not an attractive option. This prompted an additional package, freckle-env, which in this PR freckle-app reexports to avoid any change for users.
• Freckle.App.Exception - this was replaced by dropping down to the underlying annotated-exception library, though I copied the definition of annotatedExceptionMessageFrom into freckle-kafka.
• Yesod.Core.Lens - Inlined trivial lens definitions envL and siteL.
• Freckle.App.OpenTelemetry - dropped down to the underlying hs-opentelemetry-sdk package, with producerSpanArguments and consumerSpanArguments being trivial inlines.
• Freckle.App.Async - I avoided these dependencies by pushing the forking responsibility onto downstream users, though the changes to upgrade are trivial. produceKeyedOnAsync just applies void . async, and runConsumer just applies withTraceContext . immortalCreateLogged. These are noted in the changelog.

[pbrisbin]

I like it.

• freckle-env, I'd really like to get away from this. Freckle.App.Env was created at a time envparse lacked a lot of things, so much so the the module fully implemented everything. Since then we've replaced its internals with envparse plus some things, and started working to upstream those things to envparse. I wonder if they'd accept everything we have here. Until such time, I think freckle-env a fine enough name. The only other thing that comes to mind is envparse-extra, which piggy backs on the convention of wai-extra or conduit-extra.
• freckle-kafka since you've made this entirely independent, it probably makes sense to not call this freckle-, but I don't really know what other distinguishing features it has 🤔

[chris-martin]

I wonder if they'd accept everything we have here.

I'll try a little. supki/envparse#24