adafruit_esp32spi_requests.py request() sets socks.settimeout() to 1 second. This is fine in many cases, but due to server, traffic, and various other issues, it may not be enough to reliably fetch data. Retries can partially resolve this, but more user control over timeouts would give users the ability to make their own trade-offs between speed and reliability.

I'd propose initially making the timeout within request() into a keyword argument with default of 1 second, and rippling it up to WiFiManager and device-specific classes like PyPortal.

Other than ping ttl and hard-coded delays and timeouts deep in ESP_SPIcontrol, everything in ESP32SPI appears to rely on the 1-second timeout set in the request (notably in socket read and readline). Other than ping and wifi scans, NINA firmware doesn't seem to introduce any substantial delays or timeouts that I could find. I'm not sure what the ESP core does. I haven't tested to determine if there's a max name lookup time within the system (DNS servers will eventually time out and provide an error response).

Ideally (long-term), perhaps users could have separate control over timeouts for name lookup, connections, and requests. In theory, CircuitPython users would typically be fetching more concise payloads than a typical web user, but for reference, browsers have many-second timeouts for connections and requests. cURL also has separate connection and overall timeouts, with relatively high defaults (300 on connection, ∞ on the overall request). We don't need to be concerned about persistent connections for now since ESP32SPI uses HTTP/1.0 and there is no keep-alive.