Provides more MatchFunc and code movement for it

[dengsh12]

Proposed changes

In #97 , we provided a new field DirectiveSources in ParseOptions. It is an array of MatchFunc to specify the OSS/N+ version, and dynamic modules to include for validation.

In this PR, we

• Provide enough MatchFunc for OSS/N+ version, and dynamic modules, which can be passed to ParseOptions .DirectiveSources.
• Delete ParseOptions.MatchFuncs, users should use ParseOptions.DirectiveSources instead.
• Modify some logics to accommodate it.
• Move some codes from one file to separate files for better management

Checklist

Before creating a PR, run through this checklist and mark each as complete.

• I have read the CONTRIBUTING document
• If applicable, I have added tests that prove my fix is effective or that my feature works
• If applicable, I have checked that any relevant tests pass after adding my changes
• I have updated any relevant documentation (README.md)

[ornj]

I think all the code with the directive maps should have a analyze_ prefix instead of module_ or anything else. This way they will appear in editors near the main analyze.go file.

[dakshinai]

@ornj @dengsh12 What will be the process to add a new N+ version, say R32, add it to NPlusLatest?

I do see see an overlapping list for R30 and R31, I believe specific version lists should include everything up until the version to be able to perform version specific validation? So for R32, create one if needed?

[dengsh12]

@ornj @dengsh12 What will be the process to add a new N+ version, say R32, add it to NPlusLatest?

@dakshinai It will be in later merge. We will provide a generator. If a new N+ version comes just run go generate ./.... It will fetch from some sources and create new support files.

I do see see an overlapping list for R30 and R31, I believe specific version lists should include everything up until the version to be able to perform version specific validation?

The support file for a specific version only includes the directive definitions in the source code of that version. Say the version is R31, analyze_nplus_R31_directives.go only includes the directive definitions in Nplus R31 source code(so if a directive was removed before R31 it won't appear). The field DirectiveSources provides high flexibility, you can pass MatchFunc for both R30 and R31 to include both of them for validation. I think this way is more flexible and clear?

So for R32, create one if needed?

Currently latest version is R32 so just use analyze_nplus_latest_directives.go can cover. This file will update, say R33 will release tomorrow and this file will update to R33 tomorrow, and a analyze_nplus_R32_directives.go will be generated(since it is not latest). I may caution provide both R32 and analyze_nplus_latest_directives.go will make it confused?(I assume user won't need a no-update R32 while it is the latest version)

Feel free to lmk if there're further concerns!

[xynicole]

This directive is not introduced in the Lua docs https://github.com/openresty/lua-nginx-module?tab=readme-ov-file#directives

[dengsh12]

It is a directive in /lua-nginx-module/t/data/fake-shm-module/ngx_http_lua_fake_shm_module.c. I guess they want to drop the support after a period so it is undocumented

[xynicole]

https://github.com/openresty/lua-nginx-module/blob/master/src/ngx_http_lua_module.c
we reference to this file

[dengsh12]

Both of these two files are in the lua git repo. And it seems there is still a test case for lua_fake_shm. The last commit for lua_fake_shm is 9 years ago. I think this directive is likely an outdated Lua directive(not pretty sure)?

I just run a script and it seems ngx_http_lua_module.c covers all directives except lua_fake_shm. Currently the generator can rely on it, but I'm afraid they may split ngx_http_lua_module.c or have some directive elsewhere in the future. What about generate for all directives on lua git repo, then use the lua doc as a filter? I can add it in next MR