feat: bound HTTP resources and client background lifecycle

[mahirgupta]

Summary

• add an optional response-body size limit with default-unlimited compatibility
• handle known, unknown, and transparently decompressed response lengths without limit + 1 overflow
• expose HTTP connection limits and close idle connections only for SDK-owned transports
• coordinate client-created limiter refresh and maintenance goroutines with cancellation and a wait group
• reject new background work once close starts and make repeated Close calls safe
• consolidate rate-limiter state and expire inactive entries using atomic access timestamps plus locked rechecks

This PR is stacked on perf/issue-50-allocation-pooling so lifecycle and reliability behavior can be reviewed separately from serialization and pooling.

Safety

• oversized bodies are closed without an unbounded drain
• errors.Is and errors.As work for response-size failures
• active requests are not interrupted by idle-connection cleanup
• shared/user-supplied HTTP transports are not closed by the SDK
• refresh scheduling and Close races are covered, including cancellation of in-flight refresh requests
• cleanup reloads limiter access time under the map write lock before deletion

Validation

• go test -modfile=/tmp/nosql-sdk-test.mod -count=1 ./...
• go test -race -count=1 ./nosqldb ./nosqldb/httputil ./nosqldb/internal/proto/binary ./nosqldb/types
• changed-package go vet
• full go build ./...
• 30-second malformed UTF-8 reader/writer compatibility fuzz runs

Five-VM validation used three KVStore servers and two client-side proxies/benchmark clients. The fresh-table workload used one million deterministic 1 KiB rows, 100 workers per client, normal GOGC=100, and 50/50 Get/Put operations.

Sample	Revision	Combined ops/s	Errors	Retries
A1	Baseline c3ac733	52,957.52	5 boundary cancellations	0
B1	Candidate	59,824.52	0	0
B2	Candidate	61,180.49	0	0
A2	Baseline c3ac733	50,390.95	14 boundary cancellations	0

Candidate mean throughput was 60,502.50 ops/s versus 51,674.24 for baseline, a 17.08% improvement. Runtime allocations/op fell 4.00%, and GC cycles per million operations fell 13.65%. Candidate p99 latency was also lower in both crossover samples.

Notes

The baseline failures had no SDK call and a one-microsecond recorded latency, identifying them as benchmark measurement-boundary cancellation rather than service errors. Multi-hour endurance and cloud rate-limiter churn remain follow-up validation items.

[oracle-contributor-agreement]

Thank you for your pull request and welcome to our community! To contribute, please sign the Oracle Contributor Agreement (OCA).
The following contributors of this PR have not signed the OCA:

• mahirgup@phoenix794623.dev3sub4phx.databasede3phx.oraclevcn.com

To sign the OCA, please create an Oracle account and sign the OCA in Oracle's Contributor Agreement Application.

When signing the OCA, please provide your GitHub username. After signing the OCA and getting an OCA approval from Oracle, this PR will be automatically updated.

If you are an Oracle employee, please make sure that you are a member of the main Oracle GitHub organization, and your membership in this organization is public.