Fix OOM when updating very large metadata datasources

[adimiz1]

Problem

Updating a very large metadata datasource (~100k+ entries, e.g. Best Buy's upc field, SNI-8550) with updateMetadataFieldDatasource caused OutOfMemoryError. The API echoes the whole datasource in the response, and the SDK held it in memory several times over: body String -> JSONObject tree -> Map tree. A plain HTTP client that ignores the body does not have this problem.

Changes

• New opt-in option skip_response_body: on a 200 the body is drained, not parsed, and an empty response is returned. Status and rate-limit headers are still available, and errors still throw as before.
• New overloads Api.updateMetadataFieldDatasource(id, entries, options) and Api.restoreDatasourceEntries(id, ids, options). The existing signatures are unchanged and delegate to them.
• Successful responses are parsed straight from the stream (explicit UTF-8) instead of being buffered as a String first, and the response is now closed.
• Network failures while reading the body still raise GeneralError, as before.
• A non-200 response without an error key now maps to the proper exception instead of an NPE.
• Request side is unchanged (streaming it would make the entity non-repeatable and chunked).

Compatibility

No public signature changes. The only behavior difference is the non-200-without-error-key case above. The default path still builds a full object tree, so very large datasources should use skip_response_body. A backend no_entries_in_response param would be the full fix and is out of scope.

Tests

• New DatasourceLargeResponseTest (offline, local JDK HttpServer): large response, large request, skip option, UTF-8 round trip, error mapping, missing error key, malformed JSON, empty body, non-JSON error body, dropped connection mid-body.
• The test uses 300k entries by default (override with -Ddatasource.test.entries). Run under a small heap (e.g. -Xmx256m): on the old code 3 tests fail, including the OOM; on this branch all pass.
• Full http5 live suite passes (0 failures).

🤖 Generated with Claude Code

[const-cloudinary]

I'd recommend addressing these before merging:

1. Consider adding deleteDatasourceEntries(id, ids, options). The delete endpoint also returns the full datasource (Admin API: Delete entries in a metadata field datasource), so large datasources would hit the same memory issue there. An overload matching the other two would cover it.
2. Suggest aligning the @return javadoc on updateMetadataFieldDatasource and the response mock in DatasourceLargeResponseTest with the documented response, which is {"values":[...]} (Admin API: Update a metadata field datasource) rather than the field definition.
3. Suggest checking for a null body explicitly in buildError (ApiStrategy.java:140) rather than catching NullPointerException alongside JSONException.