Redesign for use as sidecar

[solsson]

Let's explore how/if we can simplify the design when only scoping in use as a sidecar. One major difference is that we don't need to send "onupdate" to multiple replicas of dependent services.

Design:

• Group id is per pod, i.e. namespace + hostname
• We use the last committed offset to denote the last onupdate that completed successfully, so in case the cache restarts we don't miss any updates (previous strategy was to update for "new" records, i.e. based on timestamp of cache startup).
• Onupdate http is on localhost, so success/failure should be more clear than with arbitrary targets.

Questions:

• How do we deal with readiness? The dependent container shouldn't read from the cache until it is warmed, i.e. consumed to some notion of latest offset.
• Kubernetes readiness affects the outside view, so should we just respond 503 on all endpoints, ar maybe delay/abort/refuse requests?
• Should the dependent container respond to onupdate requests? Or is there a mode where failed onupdate from the cache is expected until the dependent container is deemed ready.

[solsson]

Scoped out metrics in 42d19b5. I might try to revert that once Quarkus has upgraded to Graal 19.

[solsson]

There was a kafka client upgrade in master that we've never used and never will use so I force pushed to avoid the conflict.