Replace EHS HTTP server with cpp-httplib

[Lpsd]

Summary

This swaps out the built-in web server's underlying HTTP library. The old EHS dependency is removed and replaced with cpp-httplib (a single-header library) - https://github.com/yhirose/cpp-httplib/releases/tag/v0.47.0

Main changes:

• Removed vendor/ehs and added vendor/cpp-httplib.
• Added Shared/httpd/Types.h, a small standalone header providing the HTTP request/response types that the rest of the server code used to get from EHS (HttpRequest, HttpResponse, status codes, form/query/cookie maps, etc). CHTTPD and the resource code keep using the same types and method signatures, so the change stays mostly contained to the web server layer.
• Rewrote CHTTPD to drive cpp-httplib: a catch-all handler does resource lookup and dispatch, then translates our HttpRequest/HttpResponse to and from cpp-httplib's request/response objects. Authentication, brute-force protection and connection flood handling are carried over (mostly) unchanged in behaviour.

Things worth noting for reviewers:

• The minimum Windows version is now Windows 10. cpp-httplib requires _WIN32_WINNT >= 0x0A00, so the server build define was bumped from 0x601. This drops Windows 7/8 support for the server.
• The httpthreadcount config setting still works: the worker pool is sized from it. cpp-httplib handles per-request threading rather than per-connection like EHS did, so the connection gate runs once per connection (cached) instead of once per request to avoid normal page loads tripping the flood limit. The cache is pruned by age on the existing HTTP pulse (which also expires stale logins), so it stays bounded and each new connection is still evaluated.
• The HTTP allocation stats shown in perf stats (active requests/responses/KB) are no longer available, since cpp-httplib doesn't expose those internals. They now report zero. Total bytes sent is still tracked; worth following up.
• No change to SSL/HTTPS. The built-in server has always served plain HTTP: EHS shipped SSL code but it was never compiled in (the SSL source files weren't in the build and COMPILE_WITH_SSL was never set), and CHTTPD never requested an HTTPS listener. cpp-httplib does support TLS via OpenSSL, but it's intentionally left disabled here, so the behaviour is identical; also worth following up.

Motivation

EHS is unmaintained -- cpp-httplib is actively maintained and header-only!

Test plan

Tested locally on a Windows build:

• Default web resources load correctly: tested performancebrowser and resourcebrowser (includes ajax usage).
• HTTP Basic auth works: the login prompt appears for protected resources, correct credentials log in, wrong credentials are rejected, and brute-force protection still kicks in.
• AJAX calls work, including the /call/<function> routing used by resources.
• Form and query string data is passed through to Lua page handlers.

Checklist

• Your code should follow the coding guidelines.
• Smaller pull requests are easier to review. If your pull request is beefy, your pull request should be reviewable commit-by-commit.

[Disinterpreter]

Good idea! I asked for it many times.

Can you check? May in work with #1962 for future?

[Lpsd]

Can you check? May in work with #1962 for future?

If the system, i.e Windows/Linux, supports the protocol then it can/will work (providing our implementation allows it).

[sbx320]

cpp-httplib states there's no official 32-bit support. Do we just go with it, or drop 32 bit server support?

2-bit platforms are NOT supported. Use at your own risk. The library may compile on 32-bit targets, but no security review has been conducted for 32-bit environments. Integer truncation and other 32-bit-specific issues may exist. Security reports that only affect 32-bit platforms will be closed without action. The maintainer does not have access to 32-bit environments for testing or fixing issues. CI includes basic compile checks only, not functional or security testing.

[Lpsd]

Do we just go with it, or drop 32 bit server support?

I'm fine with this, since we're already enforcing W10+ for the 1.7 release on both client and server. Nobody should be using 32-bit W10, as discussed elsewhere the last release for 32-bit W10 was 2021 (IoT).

Furthermore the stats for client show less than 0.001% of users are on 32-bit Windows.

As for Linux, we have the 32-bit server. Unfortunately I couldn't locate any stats or useful information around usage, but I don't feel like it's worth supporting anymore.

I've added some commits which switch to using the 64-bit server in the client, and prevents 32-bit OS users from using local server functionality (shows a CEGUI dialog on clicking host game / map editor, asking them to upgrade OS). Tested and working fine.

In another PR we should clean up any other 32-bit server references, such as in nightly.msi, and also do the same with our internal build pipeline, ready for 1.7 release (no longer building/shipping 32-bit server binaries).