Accept the asterisk form for OPTIONS

[nigrosimone]

OPTIONS * HTTP/1.1 gets a 400 (Http11Probe COMP-OPTIONS-STAR), because consumeRequestLine wants the target to start with /. RFC 9112 3.2.4 defines the asterisk form for a server-wide OPTIONS.

The fix also accepts * when the method is OPTIONS. Other methods with * still get 400 (COMP-ASTERISK-WITH-GET). The app sees * as URL, so a /* route gets it. The check runs only when the target does not start with /.

The new test sends OPTIONS * and GET *, it fails without the fix.

With Http11Probe locally only COMP-OPTIONS-STAR moves, from Fail to Pass: 158/159.

---

for 159/159

The last one is COMP-HTTP10-DEFAULT-CLOSE: today every HTTP/1.0 request gets a 400. Accepting it is about 6 lines (request line, ancientHttp, no automatic 100 Continue and no WebSocket upgrade for 1.0), but it changes behavior, so I ask first: do you want uWS to accept HTTP/1.0?

[uNetworkingAB]

I don't think it makes sense to implement a bunch of ancient Http 1.0 rules when (ironically) the task we have is to implement the latest version of Http1.1. I think it's far easier to focus on making Http1.1 standards compliant and just cut Http 1.0 out entirely.