Tracking: parity with lua-resty-http (drop-in for ai-proxy)

Tracking issue for making ngx_http_ffi_client a drop-in replacement for lua-resty-http, so ai-proxy (EE + APISIX) can use it and cut outbound CPU on the AI gateway path.

Design / rationale: RFC api7/rfcs#115. This carries forward and supersedes the HTTPS / streaming / integration backlog sketched in the roadmap #1.

TLS is Slice 1 (the hard unblocker: every provider endpoint is an https hostname), then DNS. The stateful object, the frozen ABI, and both read paths (buffered + incremental streaming) land together as one slice, since they share the same connect/read machinery and the ABI that ties them is already frozen.

Dependency note: on main today only the one-shot request_uri path exists; the stateful object is a validated prototype on a branch. Slice 1 builds the shared TLS handshake machinery and wires it into request_uri first; Slice 3 reuses it when the stateful connect merges. The frozen ABI means no rework across that split.

Slices

• Slice 1: TLS (https, SNI, ssl_verify) #14
• Slice 2: DNS resolution in C #15
• Slice 3: stateful object + frozen ABI + buffered and streaming reads #13 (streaming design detail: #12)
• Slice 4: framing hardening #16
• Slice 5: integration and cutover #17

Each slice is independently shippable, testable, and PR'd. Where the EE/APISIX shared ai-transport/http.lua is touched (Slice 5), it is coded serially and word-for-word identically.

Open decisions

• TLS backend (Slice 1): roadmap #1 constrains TLS to rustls (sans-io, no OpenSSL/BoringSSL C bindings); nginx's built-in OpenSSL is the far-cheaper alternative that contradicts that constraint. Resolve before Slice 1 implementation.

Start with RFC api7/rfcs#115 and roadmap #1, then review slice issues #14, #15, #13, #12, #16, and #17. Resolve the TLS backend decision before implementation; done means the five independently shippable slices provide parity with lua-resty-http and support the planned ai-proxy integration.