feat(eth): port mesh/http to RP2350 + W5500 (HTTP/80 + HTTPS/443)

[cvaldess]

Summary

Ports the phone-API endpoints that today only ship on ESP32 (mesh/http/ContentHandler) over to RP2350 boards with W5500 Ethernet. Adds:

• HTTP server on TCP/80 exposing /api/v1/{fromradio,toradio} over the existing arduino-libraries/Ethernet stack.
• HTTPS server on TCP/443 reusing the same handlers via a IStreamReadWrite abstraction and an mbedTLS source-compiled TLS engine with a self-signed ECDSA P-256 cert (SAN=IP) persisted under LittleFS.

The new feature is off by default — gated by HAS_ETHERNET_API (HTTP/80) and HAS_ETHERNET_TLS_API (HTTPS/443). No upstream variant enables these flags in this PR; W5500 variants can opt-in independently.

Why two servers and not Mongoose / esp32_https_server?

The existing mesh/http/ implementation depends on esp32_https_server, which is not portable to arduino-pico, and Mongoose's built-in TCP/IP stack conflicts with the active EthernetServer used by OTA / MQTT / NTP. The cleanest path was to keep using arduino-libraries/Ethernet for the socket layer and bring our own HTTP/TLS code on top, sharing handlers between the two transports.

Architecture

                +----------+         +----------+
                | TCP/80   |         | TCP/443  |
                +----+-----+         +----+-----+
                     |                    | mbedtls_ssl_read/write
                     v                    v
       EthernetClientStream         TlsClientStream
                     \                  /
                      v                v
                   IStreamReadWrite (Print)
                              |
                              v
                       parseRequest()
                              |
                              v
                    handleApiClient()
                       |          |
                       v          v
                handleFromRadio  handleToRadio  (-> PhoneAPI)

• ethApiHandlers.{h,cpp} — Request struct, parser (CORS + Content-Length), EthHttpAPI : PhoneAPI (api_type = TYPE_HTTP, checkIsConnected = true).
• ethApiServer.{h,cpp} — listener on TCP/80, accept loop on its own OSThread (20 ms tick).
• ethTlsApiServer.{h,cpp} — listener on TCP/443, same OSThread pattern, wraps EthernetClient in an mbedtls_ssl_context.
• ethCert.{h,cpp} — first-boot ECDSA P-256 keygen + self-signed cert with KeyUsage(digitalSignature + keyEncipherment, critical) + ExtendedKeyUsage(serverAuth, critical). Generation runs once on a dedicated OSThread; result persisted under /prefs/eth_*.der and reloaded on subsequent boots.
• scripts/add_mbedtls_sources.py — vendors mbedTLS 3.6.2 (the copy already in pico-sdk) via BuildSources() so the build doesn't depend on a precompiled lib that arduino-pico doesn't ship.
• src/mbedtls_user_config.h — strips TIME / NET_IO / FS_IO / TIMING / PSA storage, defines MBEDTLS_NO_PLATFORM_ENTROPY (the platform check in entropy_poll.c is not flag-gated). Keygen and the f_rng path use pico-sdk's get_rand_64() directly, bypassing mbedtls_entropy.
• rp2040Loop() — adds an RP2xx0 hardware watchdog (watchdog_enable(8000, true)) pet from the main loop. Required because the TLS handshake on Chrome can hold the OSThread inside mbedtls_ssl_read() past 8 s; the netRecv poll loop pets the watchdog every 2 ms so a quiet client cannot starve it.

Performance

HTTP/1.1 keep-alive across both servers — handleApiClient loops on the same connection until the peer closes or parseRequest hits its 3 s idle timeout. Measured against client.meshtastic.org doing its initial sync (~80 sequential /api/v1/fromradio polls = MyInfo + every Config_* + every ModuleConfig_* + every NodeInfo):

• Before keep-alive: 80 × ~625 ms ECDSA P-256 handshake = ~50 s of pure handshake overhead.
• After: one handshake (641 ms, CHACHA20-POLY1305), all 80 requests pipelined, full config + 40 NodeInfos in ~6-8 s. Per-request post-handshake latency ~10-25 ms.

Validation

Validated end-to-end against a WIZnet W5500-EVB-Pico2 + E22-900M30S board on the local network:

• OPTIONS /api/v1/fromradio → 204 with CORS + X-Protobuf-Schema.
• PUT /api/v1/toradio (ToRadio{want_config_id=1}) → 200 + echo.
• GET /api/v1/fromradio?all=true → 200 + ~3500 B (config + channels + nodeinfos).
• GET /api/v1/nonexistent → 404.
• HTTPS handshake via curl -kv and via Firefox / Chrome / Edge after accepting the self-signed cert; curl with two URLs reports Reusing existing https: connection and the server returns Connection: keep-alive explicitly.
• Watchdog reboot stress: held a Chrome Test Connection open through idle periods > 8 s — no watchdog reset, no socket exhaustion across back-to-back requests.

Cert generation timing: ~430 ms ECDSA P-256 cold boot on the dedicated OSThread (off the Periodic stack, off the Ethernet reconnect path).

Build impact

Numbers from the wiznet variant on a downstream build that enables both flags:

• HTTP-only (HAS_ETHERNET_API): +~11 KB flash, +1.8 KB RAM.
• • HTTPS (HAS_ETHERNET_TLS_API): +~600 KB flash (mbedTLS + cert path), +~50 KB RAM. The cert key + DER blobs are heap-allocated only during gen and freed after persist.

Not included

• No variant in this PR enables HAS_ETHERNET_API / HAS_ETHERNET_TLS_API. Activation lives in the W5500 variant configs (separate PRs).
• No OTA endpoints over HTTP/HTTPS. The existing HAS_ETHERNET_OTA path lives in feat: add Ethernet OTA support for RP2350/W5500 boards #10136 and is unchanged. A follow-up commit can route OTA through handleApiClient once that lands.

Files

• New: scripts/add_mbedtls_sources.py, src/mbedtls_user_config.h, src/mesh/eth/{ethApiServer,ethApiHandlers,ethCert,ethTlsApiServer}.{cpp,h}.
• Modified: src/mesh/eth/ethClient.cpp (2 init/loop hooks gated by the new flags), src/main.cpp + src/main.h (RP2040 loop hook), src/platform/rp2xx0/main-rp2xx0.cpp (watchdog enable + poke).

Net diff: 14 files changed, 1353 insertions(+), 1 deletion(-).