Fix telemetry performance issues

[spbolton]

Telemetry Performance Improvements

This PR addresses several critical issues in the telemetry implementation that were impacting system performance and stability. The changes focus on thread pool management, memory usage optimization, and database operation efficiency.

Thread Pool Configuration Improvements

• Replaced unbounded queue with a bounded queue (1000 capacity) in ApiMetricFactorySubmitter
• Set reasonable thread pool sizes (default: 4, max: 10)
• Implemented thread-safe initialization using AtomicReference
• Added proper error handling for rejected executions

Memory Usage Optimization

• Limited request buffering to 1MB in ApiMetricWebInterceptor
• Added proper resource cleanup in the RereadInputStreamRequest
• Prevented unnecessary buffering of large request bodies
• Improved stream handling with proper cleanup

Database Operation Efficiency

• Implemented batch processing in ApiMetricAPIImpl to reduce database overhead
• Added queue-based collection of metrics with scheduled batch processing
• Improved transaction handling with proper exception management
• Added index to the metrics_temp table to improve query performance

Error Handling and Resilience

• Ensured telemetry issues don't affect core application functionality
• Added debug-level logging for telemetry errors instead of propagating exceptions
• Implemented graceful shutdown of resources

These improvements should significantly reduce the performance impact of the telemetry system on the server, preventing memory leaks, thread pool exhaustion, and database bottlenecks.

[dotcms-github-app]

Please use a Conventional Commit title format for this PR. For more information, see https://www.conventionalcommits.org/en/v1.0.0/

[jdotcms]

the interceptors already does that on the getFilters, you can limited the request scope right there

[github-actions]

This PR is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.