Captive portal feature causes memory leak

[mcspr]

Bug description
WIFI_AP_CAPTIVE=1 causes memory exhaustion when Android phone is connected to the softAP. Base available heap (running Core 2.6.0-dev) of 30k on base build for nodemcu-lolin is decreased to 15k in about 10 seconds. Can get as low as 3k. If left alone for some time, it reboots due to OOM exception.

Steps to reproduce

• launch softAP mode
• connect to the AP and wait a bit
• check heap output using serial / telnet 192.168.4.1

Device information
Testing device is a phone running Android 9
Board flavour does not matter, only that the webui is enabled and WIFI_AP_CAPTIVE is on.
Tested with base builds using Core 2.3.0 and newest git + lwip2. By coincidence or not, lwip2 builds cause much more rapid exhaustion. The connecting device is issuing a lot of requests to non-existent pages (like generate_204, gen_204 etc.), which seem like the root cause

Maybe TCP connections are kept alive somehow? Or server library is missing some clean-up routine?

[mcspr]

@xoseperez If web handlers can handle these:
https://github.com/tripflex/captive-portal/blob/3a6c6c7cb6e0e5e17680107bff0224c7b79bdcdb/src/mgos_captive_portal.c#L352-L365
On Android I see notification that opens built-in browser with the page redirect provided by the portal.
Redirect page can be anything, but in our case it may be interesting to have wifi configuration there.
Only problem is that it does not work with HTTP auth (is this an android issue?), and such page must not send out auth request.

If we send out proper answer, device stops bugging us with captive portal checks. No memory leaking that way.