Add LuaJIT backward compatibility integration tests

If you are reporting any crash or any potential security issue, do not open an issue in this repo. Please report the issue via emailing envoy-security@googlegroups.com where the issue will be triaged appropriately.

Title: Add LuaJIT backward compatibility integration tests Area: Lua filter, Testing

Description:

Problem:

The Envoy Lua filter (envoy.filters.http.lua) allows users to execute custom Lua scripts, and it relies on LuaJIT for script execution. The LuaJIT dependency is periodically updated in bazel/repository_locations.bzl to incorporate new features, performance improvements, or security fixes.

Currently, there are no integration tests specifically designed to detect regressions or behavioral changes in LuaJIT's standard libraries (table, string, math, bit, etc.) when the version is upgraded. A future LuaJIT upgrade could inadvertently introduce subtle, backward-incompatible changes that break users' existing Lua scripts, which rely on the consistent behavior of these libraries.

Proposed solution:

To mitigate this risk and make future LuaJIT upgrades safer, we should introduce a new integration test case to test/extensions/filters/http/lua/lua_integration_test.cc. This test will be dedicated to verifying LuaJIT backward compatibility by executing a script that uses commonly relied-upon language features and library functions, then asserting that their output remains as expected.

This test should cover features such as:

• Table iteration behavior (e.g., ipairs)
• String manipulation (e.g., string.gsub)
• Math functions (e.g., math.floor)
• Bitwise operations via the LuaJIT bit library (e.g., bit.band) and so on...

Adding this targeted test case will provide greater confidence that LuaJIT upgrades do not introduce breaking changes for users of the Lua filter.

Example Implementation:

A new test case, LuaJITBackwardCompatibility, can be added to LuaIntegrationTest. This test would configure the Lua filter with inline code that exercises the features mentioned above and writes the results to request headers. The test would then verify that the upstream request headers contain the expected values.

-- Example Lua code for the test
function envoy_on_request(request_handle)
  -- table iteration
  local t = {"a", "b"}
  t[5] = "e"
  local str_ipairs = ""
  for i,v in ipairs(t) do
    str_ipairs = str_ipairs .. i .. v
  end
  request_handle:headers():add("compat_ipairs", str_ipairs) -- expected: 1a2b

  -- string.gsub
  local s = "hello world"
  s_gsub = string.gsub(s, "l", "L")
  request_handle:headers():add("compat_gsub", s_gsub) -- expected: heLLo worLd

  -- math.floor
  request_handle:headers():add("compat_math_floor", tostring(math.floor(3.14))) -- expected: 3

  -- bitwise operations
  if bit then
    request_handle:headers():add("compat_bit_band", tostring(bit.band(3, 1))) -- expected: 1
  else
    request_handle:headers():add("compat_bit_band", "not_supported")
  end
end

This ensures that essential Lua functionalities remain stable across LuaJIT updates, preventing unexpected behavior in production environments where Lua filters are deployed.

[optional Relevant Links:]

Any extra documentation required to understand the issue.