Incl.:
1. Logger names are now used as namespaces.
- For SLF4J: these are typically class names.
- For tools.logging: these are typically *ns* strings.
2. These now have dedicated :kind (:slf4j, :tools.logging) to make it
easier for users to set kind-specific min levels.
- Simplified some util name (only relevant to folks customizing handler behaviour)
- Merged `format-signal->edn-fn`, `format-signal->json-fn` to single `pr-signal-fn`
Only downside/hesitation is that this info *must* be collected at the callsite,
which means that it affects the performance of *all* created signals.
Adds ~30-50 nsecs per signal.
Previously:
It was possible to provide a vector of middleware fns when creating
signals or adding handlers, e.g.:
(event! ::ev-id1 {:middleware [fn1 fn2 ...]}),
(add-handler! ::handler-id1 <handler-fn> {:middleware [fn1 fn2 ...]})
After this commit:
Middleware is always expected to be a single fn, or nil.
A `comp-middleware` util has been added to make it easy to compose multiple
middleware fns into one.
Motivation:
The previous (auto-composition) behaviour was nice when adding handlers,
but incurred a (small but non-trivial) runtime cost when creating signals.
The actual benefit (convenience) of auto-composition is very small, so
I've decided to just remove this feature and add the `comp-middleware` util.
Note that I ruled out the option of doing auto-comp only when adding handlers
since that've meant an inconsistency and so complexity for little benefit.
These seem to cause intermittent issues with GitHub actions. Seems like GHA might
be caching builds somehow, even when a caching action isn't present?
Can't reproduce locally, and haven't had an opportunity yet to identify or fix the
underlying cause, so just disabling these for now.