Fix early return in multi-batch metric scraping

[courageJ]

PR Description: Fix early return in multi-batch metric scraping

Problem

In kubelet-to-gcm/monitor/poll.go, the Once function splits metrics into multiple batches (sub-requests) to avoid exceeding API limits. However, the current error handling logic uses an early return if any batch fails to be written to Google Cloud Monitoring.

This causes all remaining batches in the same scraping cycle to be skipped, even if they would have succeeded. This leads to unnecessary data loss during intermittent API failures or if a single batch contains a malformed metric.

Additionally, the code contained verbose JSON marshalling and logging of failed requests, which adds unnecessary overhead and log noise.

Solution

1. Replace return with continue in the batch processing loop. This ensures that a failure in one batch does not prevent subsequent batches from being attempted.
2. Remove the verbose MarshalJSON and log.Warningf of the full JSON request to improve logging hygiene and performance.

Testing

• Verified that the code compiles successfully (go build ./...).
• Manual code review confirms that the loop now correctly proceeds to the next iteration on error.