Use warning logging instead of stderr print for HTTP retries

[MatufA]

Problem

LogRetry.increment() writes retry diagnostics directly to sys.stderr with print():

if response:
    print(
        f"Retrying {method} {url} for {response.status} status code....",
        file=sys.stderr,
    )
else:
    print(
        f"Retrying {method} {url} due to error: {error}",
        file=sys.stderr,
    )

When application logs are collected and sent to Datadog, this raw stderr output can be buffered together with neighboring application logs. Because it bypasses Python logging, the retry message has no standard log level or logger metadata, which causes discrepancies in downstream log parsing.

Impact

• Retry messages may be grouped with unrelated log records in Datadog.
• Log parsers cannot consistently identify the retry event or its severity.
• SDK users cannot control these messages through their normal Python logging configuration.

Proposed change

Use a module logger and emit retry events at warning level:

import logging

logger = logging.getLogger(__name__)

if response:
    logger.warning(
        f"Retrying {method} {url} for {response.status} status code...."
    )
else:
    logger.warning(
        f"Retrying {method} {url} due to error: {error}"
    )

A retry is recoverable, but it represents an abnormal request path, so WARNING communicates the event without treating it as a terminal failure. The SDK should not configure logging itself; callers should retain control of handlers and formatting.

Acceptance criteria

• LogRetry.increment() no longer writes retry diagnostics directly to stderr.
• Response-triggered and error-triggered retries emit a WARNING through Python logging.
• Tests cover both retry-message paths using log capture.
• Existing retry behavior and retry counters remain unchanged.

Feedback on this approach is welcome before implementation.