Fix Failing Tests, Address Client Connection Issue

[jhoughjr]

Updated from swift-tools-version:5.7 to 5.9.
This fixes an issue where clients would get a bad Sec-WebSocket-Accept value from vapor.

Fixed bad url tests on WebSocket, Async and regular.

There is an issue for covering all bad urls that the WebSocket might reject as URL seems to init fragments such as bare escape sequences. I'm not sure yet how that could be covered better, or how important it is.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 82.85%. Comparing base (a935b63) to head (2859454).
⚠️ Report is 12 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #155   +/-   ##
=======================================
  Coverage   82.85%   82.85%           
=======================================
  Files           6        6           
  Lines         659      659           
=======================================
  Hits          546      546           
  Misses        113      113           

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[gwynne]

The semantics of URL's validation changed noticeably in Swift 6.0, hence the CI failure.

[0xTim]

We really shouldn't be touching BoringSSL anymore

[gwynne]

We really shouldn't be touching BoringSSL anymore

Yeah, but that's out of scope for this PR.

[jhoughjr]

Ill check these tests and update.

[jhoughjr]

Im beginning to think there is no way to resolve this issue with this test. The behavior is not consistent enough across swift versions and platforms. The utility of the test is unknown to me also.

I don't know how to even do it (much less elegantly), to handle URL initialization across versions and platforms.
I'd also argue this is kinda testing URL and we don't own that. idk im not of much use.

[0xTim]

I didn't realise this was building! @gwynne any comments on this?

[hiSandog]

For the client connection test fix, it would be useful to include a failure-path case as well as the happy path. A local server that accepts the TCP connection and then closes during the WebSocket upgrade would prove the client cleans up futures/channels deterministically. That is usually where flaky tests hide, because success paths complete quickly while failed handshakes can leave event-loop work pending.