perf(core): cache parsed JSON request body to avoid redundant decoding

[AlinsRan]

Summary

get_json_request_body_table() previously called json.decode() on every invocation with no caching. In the ai-proxy plugin request path, this function is called 3 times per request across different phases:

Request
  │
  ├─ Route matching (access phase, ctx.lua)
  │    └─ post_arg.* variable resolution
  │         └─ get_json_request_body_table()   ← decode #1
  │
  ├─ ai-proxy access phase (ai-proxy/base.lua: detect_request_type)
  │    └─ detect protocol (chat / responses / anthropic), extract model
  │         └─ get_json_request_body_table()   ← decode #2
  │
  └─ ai-proxy before_proxy phase (ai-proxy/base.lua: before_proxy)
       └─ build upstream HTTP request, apply model options, auth
            └─ get_json_request_body_table()   ← decode #3

(+ decode #4 if ai-rag or ai-aliyun-content-moderation plugin is also active)

Each decode is redundant: the body bytes have not changed between phases.

Changes

apisix/core/request.lua

• Add get_request_body_table(ctx): a unified, content-type-aware body parser that handles application/json, application/x-www-form-urlencoded, and multipart/form-data. Caches the parsed result in ctx._request_body_tab for the lifetime of the request.
• Rewrite get_json_request_body_table() as a thin wrapper: validates Content-Type is application/json (returning an error for non-JSON requests to prevent type confusion), then delegates to get_request_body_table().

apisix/core/ctx.lua

Remove the local _get_parsed_request_body / get_parsed_request_body functions and the multipart dependency. The post_arg.* variable resolution now calls request.get_request_body_table(ctx) directly, sharing the same cache.

apisix/patch.lua

Simplify the set_body_data patch: use _request_body_tab as the single guard. If it is non-nil, clear it and scan var._cache for stale post_arg.* entries. If it is nil, body was never parsed — skip both cleanups entirely.

Performance

Benchmarked on a single APISIX worker with a mock upstream (100 ms fixed delay, ~10 KB response):

Body size	Before (3 decodes/req)	After (1 decode/req)	Gain
1 MB	~70 RPS	~180 RPS	+157%
10 MB	~7 RPS	~16 RPS	+129%

CPU was the bottleneck in all cases. Gain scales with body size because json.decode cost grows linearly with input.

Test

Added TEST 17 in t/core/request.t:

• Patches json.decode with a call counter
• Verifies 3 successive calls produce only 1 decode and return the same table object
• Calls ngx.req.set_body_data() to replace the body, then verifies the next call re-decodes (counter becomes 2) and returns the new content