Demo: do not use glue code for accept4

[armanbilge]

@LeeTibbert following up on #50 (comment). I removed the @name to delegate directly to the method without the glue code.

Fails locally with:

==> X epollcat.TcpSuite.local and remote addresses 0.01s munit.ComparisonFailException: /workspace/epollcat/tests/shared/src/test/scala/epollcat/TcpSuite.scala:119
118:                assertEquals(clientRemote, serverLocal)
119:                assertEquals(serverRemote, clientLocal)
120:              }
values are not the same
=> Obtained
/A00:D032:0:0:0:0:0:0:0
=> Diff (- obtained, + expected)
-/A00:D032:0:0:0:0:0:0:0
+/0:0:0:0:0:0:0:1:53298

[LeeTibbert]

Ah! The heavy weight of the past! I think I owe you a beverage for this one.

Just a day or two ago I wrote you a "heads up" that the sockaddr_in6 structure
is declared wrong (for overlay) in SN 0.4.n. I bet that is what is going on here.

Let me study it. Time taken to write tests sure pays off.

[armanbilge]

Ah, now we come full circle 😂

Yes, I was aware of these issues, since you first mentioned them in scala-native/scala-native#2626 and said they required binary-breaking changes to fix. That is why I wrote in #3 that I believed IPv6 to be very broken in SN 0.4.x, both in Javalib and Posixlib. Please tell me that is not the case 😂

Edit: er, nvmd, I may be confusing issues, sorry 😕 in any case I hope we find a way to make this all work.

[LeeTibbert]

I believe this PR can be closed, possibly with a note in the accept4 C code that it can go away
once 0.4.n is no longer supported.

Re: believed IPv6 to be very broken in SN 0.4.x, both in Javalib and Posixlib

With one small exception dealing with UDP methods, posixlib IPv6 should be healthy in 0.4.n
if you discover anything, I ought to fix it.

You are entirely correct that Javalib IPv6 is, IMO, busted beyond backport. We have been
living a lot of those reasons the past few days. epollcat has the liberty to implement some
things that are "too much change" for a stable release stream.

Your getting IPv6 to work in epollcat based on SN 0.4.n was pretty bold but seems
to be paying off.

[LeeTibbert]

An upcoming LLVM (15? just out) is going the support "randomize structures". Now
that ought to make life interesting. A pretty useless flag for user code, but
somebody is going to do it.

[armanbilge]

Phew, ok thanks for calming my fears :)

[LeeTibbert]

Well, one of them. You have so many irons in the fire it is a Good Life if you
have only one.

I am off to fix 0.4.n InetAddress.getByName returning IPv6 addresses. Then
I am diving into simplifying & correcting InetAddress itself. Talk about Fear!
The changes I am going to try are based on my suspicions before the fact
being confirmed by what you did in epollcat.

I am on reserve (and out of your hair) for a while. If I can be useful to epollcat
or the typelevel ecosystem. Now that I am a little trained up, that training
time might be put to good use.