add more logging, retry, caching functionalities

[sethupavan12]

This PR introduces three cross-cutting improvements to enhance the codebase’s resilience and observability:

• Structured and Enhanced Logging: Improved debuggability by adding structured logging hooks (info, debug, warn, error) and expanding log statements around I/O and network operations.
• Automatic Retry Logic: Implemented retry utilities for network or flaky operations with configurable retry policy (max attempts, base backoff, max backoff, jitter).
• Simple, Configurable Caching Layer: Introduced a caching component with configurable TTL and capacity to reduce duplicate work and external calls by memoizing frequently-requested results.

What Changed:

• Added structured logging hooks (info, debug, warn, error) and expanded log statements around I/O and network operations.
• Implemented retry utilities for network or flaky operations with configurable retry policy (max attempts, base backoff, max backoff, jitter).
• Introduced a caching component with configurable TTL and capacity to memoize frequently-requested results and avoid repeated expensive operations.
• Added unit tests and some integration tests covering retry and cache behavior.
• Updated configuration (defaults + environment/config keys) to enable tuning of logging level, retry policy, and cache parameters.

Motivation:

• Reduce transient errors and improve reliability by retrying them instead of failing immediately.
• Improve performance and reduce load on downstream services by caching repeated results.
• Simplify troubleshooting and speed up the process through more consistent and structured logging.

Behavioral Details:

• Retry Policy: Implemented exponential backoff with optional random jitter. Retries are only for transient errors (e.g., network timeouts); non-retryable errors are returned immediately.
• Cache: In-memory cache with TTL per entry and an upper size limit. Entries expire after TTL or when capacity is exceeded (LRU/eviction policy).
• Logging: Includes context (operation, correlation/request IDs where available), timestamps, and log levels. Logging verbosity is governed by configuration.

Configuration:

• New Config Keys (Examples):
  • LOG_LEVEL (default: info)
  • RETRY_MAX_ATTEMPTS (default: 3)
  • RETRY_BASE_BACKOFF_MS (default: 100)
  • RETRY_MAX_BACKOFF_MS (default: 2000)
  • CACHE_TTL_SECONDS (default: 300)
  • CACHE_MAX_ENTRIES (default: 1000)
    These defaults are conservative; adjust them based on your environment.

Backward compatibility:

Default settings preserve previous behavior whenever possible (e.g., conservative retries and disabled/limited caching unless configured).

No breaking public API changes are expected. If you rely on exact timing or side effects from repeated attempts, verify the behavior with retries and caching enabled.

Testing:

Unit tests have been added for:

• Retry logic (success after retries, abort on non-retryable errors, and backoff timing)
• Cache behavior (set, get, eviction, and TTL)
• Presence of logging statements (basic smoke checks)

Manual/integration tests:

• Verified request flow with a flaky endpoint to confirm that retries reduce failures.
• Verified that caching reduces the number of outbound calls for repeated requests.

How to review:

Focus areas:

• Correctness of retry decision logic (what is considered retryable).
• Cache eviction and TTL handling (to ensure no memory leaks).
• Logging coverage and that sensitive data is not being logged.

Suggested review order:

• Retry utilities
• Cache implementation
• Places where retry or cache are wired into existing flows
• Tests

Known limitations and follow-ups:

• The current cache is in-memory. Consider using a distributed cache (Redis or memcached) for multi-instance deployments.
• The retry policy is centralized but could be extended with per-call policies for more fine-grained control.
• Logging could be further improved by standardizing correlation IDs across requests (follow-up task).