T-1365 Send queued logs when the JVM exits

[PetrHeinz]

The sender runs on a daemon thread, so an application that returns from main without stopping logback takes the JVM down with whatever is still queued in the appender: the docs' own "start logging" example (log a line, return) never sends anything unless the batch interval happens to fire first. And even when logback is stopped explicitly, stop() returned immediately whenever a flush was already in progress on another thread, leaving the in-flight batch and anything queued behind it to the daemon thread that the exiting JVM then kills.

Two changes in LogtailAppender:

• start() registers a JVM shutdown hook that calls stop(), and stop() deregisters it again so contexts stopped normally (logback's own <shutdownHook/>, Spring Boot, tests) don't accumulate hooks. When stop() runs from a hook, ours or logback's, removeShutdownHook throws IllegalStateException; that is the one case deliberately ignored.
• The isFlushing flag becomes a ReentrantLock held for the whole flush, including the sub-batch loop that used to be a recursion. flush() still skips when another flush holds the lock; stop() now blocks on it, marks the appender stopped so no new events slip in, and sends everything left. Subclasses that read the protected isFlushing field can use flushLock.isLocked() instead.

The test decorator's private lock existed only to wait for an asynchronous flush, so it now waits on the appender's lock instead.

The first commit is the two failing tests on their own and is expected to fail CI: one spawns a JVM that logs a line against a local HTTP server and returns from main, the other holds a flush inside the request and checks that stop() waits for it. The second commit makes them pass.

🤖 Generated with Claude Code