startWifi / startCaptivePortal behavior

[GregAscolab]

Description

Looking at source code, behavoir of:

1. IPAddress AsyncFsWebServer::startWiFi(uint32_t timeout, CallbackF fn ) (l.585) and
2. IPAddress AsyncFsWebServer::startWiFi(uint32_t timeout, const char *apSSID, const char *apPsw, CallbackF fn) (l.668)

seems strange to me...

Remark 1: 2 is calling 1, and both functions check to start captivePortal if they can't connect to Wifi network. It seems redundante to me.

Remark 2: According different example, it is needed to run server.updateDNS(); in main loop to handle DNS requests. But using startWifi, we don't know if we've been connected to existing wifi network or if it has started a captivePortal.

Maybe interesting to have captive portal status info inside the webserver class in order to test it directly (avoiding managing captiveRun flag somewhere in code, and forget to test it...)

[cotestatnt]

Hi @GregAscolab You are right. I need to review this method in order to offer more possibilities of operation. I usually prefer that the ESP goes into AP mode when there is no WiFi, but some people might want a different behavior, so the idea is to eliminate the "automatisms" and explicitly call the library methods to enable one or the other functionality.

The captive portal idea is excellent, I will definitely implement it, thanks!

[cotestatnt]

Added getCaptivePortal() in laste relase. I've modified also a little the connection methods.