Make google_gax compatible with tesla >= 1.18.3

[alan]

Fork patch restoring compatibility between google_gax and tesla >= 1.18.3, which is otherwise a hard runtime break, so downstream consumers can bump Tesla to 1.20.

Why

tesla 1.18.3 (the fix for CVE-2026-48594) made :max_body_size a required option on Tesla.Middleware.Compression / DecompressResponse, fetched for every non-HEAD response before any content-encoding check. GoogleApi.Gax.Connection plugs DecompressResponse with [], so every generated Google API client (google_api_storage, google_api_pub_sub, google_api_logging, google_api_ai_platform) raises ArgumentError at runtime once Tesla is on 1.18.3+.

Upstream fixed this in googleapis#13328, but that PR was closed unmerged on 2026-06-30 because the repo is being archived, and google_gax will get no further Hex releases. This fork carries the identical fix.

Changes (mirrors googleapis#13328)

• connection.ex — DecompressResponse now passed max_body_size: :infinity (see security note below).
• connection.ex — multipart field names changed from atom (:metadata, body_name) to string ("metadata", to_string(body_name)). Tesla 1.18.3 Multipart.add_field/4 requires binary field names and raises on atoms via a single is_binary-guarded assert_quoted_string_safe!/2 clause — this would otherwise break GCS multipart uploads.
• mix.exs — drop the {:mime, "~> 1.0"} dep. The published google_gax never declared mime; the repo master added a ~> 1.0 cap that hard-conflicts with consumers requiring mime ~> 2.0.6 or ~> 2.1 (mime resolves to 2.0.7 under Tesla 1.20). google_gax never calls MIME directly, so removal is safe and unblocks resolution.
• connection_test.exs — explicit assertion that multipart field names are stringified.

Security note: why max_body_size: :infinity?

This is a security-motivated change that deliberately opts these clients out of the new decompression-bomb protection. That is intentional and, we believe, safe:

• The CVE concerns untrusted upstreams. These clients only ever call authenticated first-party Google Cloud endpoints over TLS with our own service-account credentials — not arbitrary origins.
• :infinity preserves the exact prior behaviour (google_gax never capped decompression), so there is no regression relative to today.
• The Tesla bump still applies max_body_size caps to all other outbound HTTP, including untrusted third-party traffic — this exemption is scoped only to the Google clients.
• Residual risk (a compromised or MITM-ed Google endpoint returning a decompression bomb) is low given TLS and Google infra; a finite cap is the defense-in-depth alternative if we later prefer one.

Test coverage

• Decompress fix: covered by the existing api_test.exs compressed/basic response tests (they would raise ArgumentError without the fix under Tesla >= 1.18.3).
• Multipart fix: covered by the existing connection_test.exs build_body tests (they would crash on atom field names without the fix) plus the new explicit string-name assertion.

Consumed by

Referenced downstream via a sparse + override git dep on clients/gax.