Retry batches answered with 429 or 5xx, and report rejected batches once

[PetrHeinz]

The HTTP outlet treats any response as a delivery (deliver_requests). A 429 or 5xx is never retried and its Retry-After is ignored, and a 401, 403 or 413 drops the batch without a word. Only exceptions are retried, and since 0.1.20 any response, a 503 included, also resets the reconnect backoff. The red-team found that a wrong source token loses 100% of the logs with no output at all.

• 2xx: delivered, and the reconnect backoff starts over, as before.
• 408, 429 and 5xx: the batch goes back on the queue and is retried like after a failed connection, with the same backoff (1 s, 2 s, 4 s, … up to 30 s) and the same limit of 3 attempts. A Retry-After header (seconds, or an HTTP date) sets the minimum wait, capped at 60 s. These responses don't reset the backoff.
• Any other status (401, 403, 413 and the other 4xx, also 3xx): the batch is dropped, and the first rejection with each status code in a process prints one warning through Kernel#warn, never through a Logtail logger. For example: Logtail: Better Stack rejected 37 log lines with HTTP 401 Unauthorized - check your source token. Further rejections with this status won't be reported.
• The Logtail::Config debug output stays. It now calls any 2xx a success, not just 202.
• The retry-or-drop logic for exceptions moved into a helper that both paths use.

Behaviour and compatibility:

• Delivery is at-least-once: if a 5xx comes back after Better Stack already stored the batch, the retry stores it again and those lines are duplicated.
• While the ingest answers 5xx, a batch waits in the request queue between its attempts, as it does while the host can't be reached, and flush/close wait for it the same way. Against a local stub answering 503 at exit, close took 2 s (three attempts); with Retry-After: 60 it waited its full 20 s limit, as for an unreachable host. The shutdown PR (claude/fast-quiet-shutdown) shortens that wait.
• Rejections now print a line on stderr, once per status code and process. ruby -W0 silences it, like any warn.
• RequestAttempt takes an optional line count for the warning.

Follow-up after the E2E run of the release candidate (two more commits, the first one only a test, red on CI): Better Stack's ingesting proxy answers 408 Request Time-out, and closes the connection, when a new connection stays unused for more than about 10 to 15 seconds. The outlet opens a new connection after every requests_per_conn requests and then waits for lines, so after a quiet spell the next batch got that 408 and was dropped with a misleading "rejected … with HTTP 408" warning; 0.1.20 lost it silently. A 408 means the server didn't read the request, so it's now retried like a 429 or 5xx, with the same backoff and attempt limit, honouring Retry-After, and without a warning.

Targets the logtail 0.1.21 patch release. No dependencies on the other open PRs; the fork-safety and shutdown PRs change other methods of http.rb.

The first commit only adds the tests and is expected to fail on CI; the fix follows in the next commit.

🤖 Generated with Claude Code