Connection pool exhausted error in Ti.Network.HTTPClient

Determine whether developers should explicitly close Ti.Network.HTTPClient instances or rely on garbage‑collection‑driven cleanup to keep the internal keep‑alive connection pool from being exhausted.

The pool defaults to five connections per host, and the framework does not document when a connection is returned to the pool after a request finishes. Observations show that omitting client.close() leads to exhaustion after a few rapid requests, while the timing of GC‑based release differs between iOS and Android runtimes.

• Does calling client.close() reliably return the underlying socket to the pool on both iOS and Android?
• If close() is omitted, what GC conditions trigger pool return, and how can they be verified reliably?
• Should developers disable keep‑alive or adjust the undocumented pool size as a workaround, or is explicit lifecycle management the only supported approach?