CI: add per-module testsuites

[thresheek]

Feature Overview

Currently, we have no way to know if a module that is shipped in pkg-oss actually works. During the PR CI phase we only check that the package builds.

The proposal is to:

• Check if the module package is installable and loadable
• Run module own tests (if possible) to determine if it actually works with the given nginx version

It's not yet clear if those additional checks should be blocking PRs or rather inform us about the possible issues. What do we do if the module is broken with the current version of nginx? We don't own that specific code, even if we provide a way to build it.

Alternatives Considered

No response

Additional Context

No response

[mschfh]

It would make sense to centralize the modules and either consider moving the existing docker-nginx tests to this repo or create a new repo for contrib tests (similar to nginx-tests), WDYT?

[thresheek]

I took a look at the third-party modules we ship, and here's a breakdown:

1. No tests at all

• fips-check
• geoip2
• ndk

2. homegrown shell scripts for CI/Travis/GH:

• auth-spnego
• brotli
• rtmp

3. ruby-based test framework:

• passenger

4. python-based test framework:

• otel

5. openresty-test-nginx-based tests, somewhat similar to what's used in nginx:

• encrypted-session
• headers-more
• lua
• set-misc
• subs-filter

6. typical nginx tests:

• acme
• njs

We'll need to decide how we want to integrate what's feasible.. Obvious candidates are group 5 and group 6, and maybe write some tests for some of the modules in group 1?

Regarding the implementation, we actually have the test-module-* targets in e.g. debian/Makefile as a leftover from the removed modsecurity support; so for the group 6 it's pretty straightforward to add.

[thresheek]

Implemented in #134