datastore.Iterator leaks database/Firestore resources on decode errors

[vanshika2720]

Title

MySQL/Firestore datastore.Iterator leaks connections on decode error

Description

• pkg/datastore/datastore.go (Iterator interface has no Close()), pkg/datastore/mysql/iterator.go:38-52
• List() calls across the datastore layer can return early on a row/document decode error without releasing the underlying sql.Rows/Firestore iterator.
• No SetMaxOpenConns is configured, so repeated failures can accumulate unreleased database resources. ListNotCompletedDeployments and similar methods are polled continuously by every piped instance, meaning a single malformed/incompatible row could eventually exhaust available MySQL connections and impact datastore operations across the control plane.
• This is distinct from the related but narrower open issue [#6699](Missing error handling on json.Unmarshal inside MySQL Row Iteration #6699), which concerns a swallowed json.Unmarshal error in the same MySQL iterator but does not address iterator/resource cleanup.

Suggested fix

Add Close() error to the datastore.Iterator interface and ensure every caller closes the iterator immediately after obtaining it:

iterator, err := ...
if err != nil {
    return err
}
defer iterator.Close()

This ensures the underlying database/Firestore iterator is released both on successful iteration and when iteration exits early because of a decode error.

Verification

The MySQL implementation can return from iteration when row decoding fails without closing the underlying sql.Rows. The Firestore implementation should be verified for the same lifecycle issue.

[vanshika2720]

I am working on this issue .