fix: remove noisy per-PID trace logs from fd usage collection

[purple4reina]

What does this PR do?

The usage-metrics monitoring loop polls /proc every 10ms and reads /proc/{pid}/fd for every PID each tick. When read_dir fails (e.g. /proc/1/fd is not readable by the extension), the existing code logged a trace! message per unreadable PID per tick. At ~40 ticks per invocation (tested with a Hello World golang function), a single persistently-unreadable PID produced ~40 trace messages per invocation (~4000 per 100 invocations).

These failures are benign — a PID's fd directory may be unreadable while the process is otherwise alive (typically a permission issue). The other /proc/{pid} readers (fd_max, threads_max, threads_use) already fail silently with continue. This change makes get_fd_use_data_from_path consistent with that behavior by removing the trace logging and dropping the now-unused trace import.

Motivation

Observed ~4000 noisy log messages per 100 invocations when trace logging was enabled, making trace output unusable for debugging.

Testing

• cargo build — clean compile, no unused-import warnings
• cargo test proc — all 8 proc tests pass, including test_get_fd_use_data
• cargo clippy — clean

Checklist

• PR description is filled out
• Tests pass

[Copilot]

Pull request overview

This PR reduces log noise in the /proc-based usage-metrics monitoring loop by removing per-PID trace! logging when /proc/{pid}/fd is unreadable, aligning fd collection behavior with other /proc/{pid} readers that already fail silently.

Changes:

• Removed trace! logging on fs::read_dir("/proc/{pid}/fd") failures (benign permission/readability cases).
• Dropped the unused trace import from tracing.
• Minor simplification: inline files.count() into the accumulator update.

[purple4reina]

Related to #535

[datadog-prod-us1-3]

✨ Fix all issues with BitsAI

⚠️ Warnings

🚦 3 Pipeline jobs failed

DataDog/datadog-lambda-extension | integration-suite: [lmi]     

DataDog/datadog-lambda-extension | integration-suite: [snapstart]     

DataDog/datadog-lambda-extension | integration-suite: [on-demand]     

Useful? React with 👍 / 👎

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 09e0f63 | Docs | Datadog PR Page | Give us feedback!}

[duncanista]

Don't think the solution is removing it, but rather reducing how often this is logged, cc @shreyamalpani since you added this code, any opinions?

[shreyamalpani]

I believe PID 1 is the Lambda init process and we are probably seeing this failure log because of a permissions issue. I think this is safe to remove for now, but if we do start seeing file descriptor metrics drop we should add this back, ignoring any failures on PID 1 as that is a known failure.