chore(deps) bump luasocket from 3.0-rc1 to 3.0.0

[bungle]

Summary

The last time LuaSocket had a stable release tag was 14 years ago when 2.0.2 was tagged.
A v3 release candidate was tagged 9 years ago.
Since then it has been downloaded over 3 million times.
Additionally the Git repository regularly gets several hundred clones a day.
But 9 years is a long time and even the release candidate has grown a bit long in the tooth.
Many Linux distros have packaged the current Git HEAD or some specific tested point as dated or otherwise labeled releases.
256 commits later and having been migrated to the @lunarmodules org namespace on GitHub, please welcome v3.

This release is a "safe-harbor" tag that represents a minimal amount of changes to get a release tagged.
Beyond some CI tooling, very little code has changed since migration to @lunarmodules (5b18e47..e47d98f):

• Lua 5.4.3+ support – @pkulchenko, @Zash
• Cleanup minor issues to get a code linter to pass – @Tieske, @jyoui, @alerque
• Update Visual Studio build rules for Lua 5.1 – @ewestbrook
• Set http transfer-encoding even without content-length – @tokenrove

Prior to migration to @lunarmodules (v3.0-rc1..5b18e47) many things happened of which the author of this changelog is not fully apprised.
Your best bet if it affects your project somehow is to read the commit log & diffs yourself.

[alerque]

Two questions:

1. It looks like the test failure(s) here are related to secsockopt(), but at least at first glance I don't see any relevant code changes since the rc1 release. Given that the rc1 doesn't even compile for me against openresty Lua, is it possible you had it patched somehow?

2. Am I seeing m1 patches in here related to luasocket? Or am I reading the CI output wrong? If so are those something that can be upstreamed?

[bungle]

Two questions:

1. It looks like the test failure(s) here are related to secsockopt(), but at least at first glance I don't see any relevant code changes since the rc1 release. Given that the rc1 doesn't even compile for me against openresty Lua, is it possible you had it patched somehow?
2. Am I seeing m1 patches in here related to luasocket? Or am I reading the CI output wrong? If so are those something that can be upstreamed?

@alerque, Thanks for getting back. I think we use luasocket in some scenarios where we don't have Nginx cosockets. That is, if we need to access e.g. database with CLI, or on some Nginx phases where there is no OpenResty support for Nginx cosockets. Everywhere else we use Nginx cosockets, and not LuaSocket.

We do have some M1 patches, but I am not aware that we patch LuaSocket in any way. I need to recheck that though, or is there any monkey patching going on anywhere or within our test suite.

[alerque]

It's possible I was reading the output wrong, I don't know what I'm looking at here. I just saw something about patching sockets and a setsockopt() error that looks like it might be LuaSocket (but not in the build, it is later it one of the unit tests.)

If there is anything you need from the LuaSocket side to get this working feel free to raise an issue. And of course if it turns out there is some monkey patching going on we'd be happy to look at upstreaming proper fixes so that everybody benefits.

[bungle]

@alerque, Seems like @Tieske opened an issue related to this on LuaSocket:
lunarmodules/luasocket#371

I am changing this to do not merge until we get resolution from upstream.

[bungle]

I will close this for now. Let's see if upstream resolves this at some point.