ci: test qjson against multiple OpenResty runtimes

[membphis]

Background

qjson is exposed to LuaJIT through FFI, and the most important OpenResty compatibility risk is not the JSON parser algorithm itself. The parser already has Rust tests, corpus coverage, fuzzing, Miri/ASan, and Lua busted coverage. The remaining gap is whether the released libqjson cdylib and Lua wrapper behave correctly under LuaJIT builds shipped with different OpenResty versions.

Kong/lua-resty-simdjson covers this kind of risk with an OpenResty version matrix. For qjson, we do not need to start with Test::Nginx or a full HTTP request lifecycle. The first useful step is a CI-only OpenResty runtime matrix that exercises both the native resty entrypoint and the OpenResty-bundled luajit binary.

Goal

Add CI coverage that proves qjson works with multiple OpenResty runtime bundles, especially their bundled LuaJIT and FFI/dynamic-library loading behavior.

Proposed Scope

Add a GitHub Actions job that:

• Builds qjson in release mode.
• Downloads/builds a small matrix of OpenResty versions, initially something like:
  • OpenResty 1.21.x
  • OpenResty 1.27.x
  • latest available 1.29.x if CI cost remains acceptable
• Uses each OpenResty installation to run two layers of checks:
  • $OPENRESTY/bin/resty smoke check for the native OpenResty CLI environment.
  • $OPENRESTY/luajit/bin/luajit as the Lua interpreter for the existing tests/lua busted suite.
• Sets the dynamic-library environment explicitly so ffi.load("qjson") resolves the freshly built cdylib from target/release.

The resty smoke should stay small and cover only runtime compatibility basics:

• require("qjson")
• qjson.parse(...):get_*
• qjson.decode(...).field
• qjson.encode(...)
• collectgarbage("collect") after dropping parsed documents/lazy proxies

Non-Goals

• Do not introduce Test::Nginx in this first step.
• Do not require a new Makefile target unless the workflow becomes hard to maintain without one.
• Do not require new reproduction docs unless the CI command sequence becomes non-obvious.
• Do not turn this into a release/package installation test; the existing LuaRocks validation already covers packaging from another angle.
• Do not add Valgrind or leak checking here. That can be a follow-up quality gate.

Acceptance Criteria

• CI has an OpenResty runtime matrix that runs on pull requests.
• Each matrix entry uses that OpenResty version's bundled LuaJIT, not the system LuaJIT, for the full Lua busted suite.
• Each matrix entry runs a small resty smoke script successfully.
• The job fails if ffi.load("qjson") cannot load the release cdylib under any selected OpenResty runtime.
• The job fails on Lua test failures under any selected OpenResty runtime.
• The implementation keeps the scope CI-focused and avoids introducing Test::Nginx unless a concrete blocker appears.

Follow-Ups

Potential later work, intentionally excluded from the first PR:

• Make one Valgrind/OpenResty runtime check blocking or add it as a scheduled job.
• Add more OpenResty versions or architectures if CI cost is acceptable.
• Add Test::Nginx only if we later need request-phase or Nginx error-log assertions.
• Add a local Makefile target if contributors need an easier way to reproduce this matrix locally.