DietPi-CloudShell: Add Pi-hole v6 REST API support for the Pi-hole scene - #8456

Post-merge review + live test

Test setup: NanoPi Zero2 (DietPi on Trixie), Pi-hole FTL v6.8 installed via dietpi-software (webserver.port = 8089,8489s). I ran dietpi-cloudshell from current dev with only the Pi-hole scene enabled, driven in a pseudo terminal, and checked the API calls directly with curl.

The stats values (ads blocked, queries, blocked domains, percentage) are correct, and session reuse works, also across an FTL restart. Three issues, though:

1. Last blocked domain is always empty
upstream=blocked is not a pseudo upstream. FTL knows only blocklist, cache and permitted (src/api/queries.c); any other value is matched against f.forward. Result: HTTP 200 with "recordsFiltered":0, and an empty line in the scene. queries?length=1&upstream=blocklist works, and so does the dedicated endpoint, which returns {"blocked":["ladsup.com"],...}. I'd suggest the latter, since its response is much smaller:

Pihole_Request 'stats/recent_blocked?count=1' || return 1
PIHOLE_LAST_DOMAIN_BLOCKED=$(sed -n 's/.*"blocked":\["\([^"]*\)".*/\1/p' <<< "$PIHOLE_RESPONSE")

2. Cached password goes stale after an FTL restart
FTL regenerates /etc/pihole/cli_pw on every start. Sessions are restored across restarts by default (webserver.session.restore = true), so this doesn't hit right away. But once the session is lost later on, the re-auth after the 401 uses the old cached password and gets "password incorrect". That happens after 1800 s without requests, e.g. with the screen blanked overnight, or when session restore is disabled. From then on the scene shows "API authentication failed" until cloudshell is restarted. I reproduced this twice. Fix: don't cache the password. It's only read on the first auth and after a 401 anyway.

3. Creating cli_pw ourselves cannot work
FTL only accepts the password it generated itself and keeps in memory (verify_login() in src/config/password.c). Tested: a self-written file is rejected with webserver.api.cli_pw = false, and with cli_pw = true FTL replaces it on start. So Pihole_CLI_Password() and the menu hook can be removed. If the file is missing, webserver.api.cli_pw is disabled, so a hint like "/etc/pihole/cli_pw missing, webserver.api.cli_pw disabled?" would help the user more.

Minor

• SID in the process list: the SID is a curl argument on every refresh, so every local user can see it with ps (caught with a ps loop). CLI sessions cannot change the config, but they can manage lists. It could go via stdin instead: curl -H @- ... <<< "sid: $PIHOLE_SID" (curl >= 7.55). The same works for the password with -d @-.
• prettyJSON: webserver.api.prettyJSON = true breaks all the sed parsing (values end up empty or 0). Probably acceptable, just noting it.
• Port parsing: it takes the first number of webserver.port. That's fine for the defaults and for DietPi's 8089,8489s, but e.g. HTTPS only (443s) or a redirect (80r,443s) would fail. Edge case.

I can open a follow-up PR for 1-3 if you like.

All addressed in #8463.

• The CLI password is passed via STDIN, and via --json option (which implies the content type).
• Redirected ports and IPv6 ports are not supported yet. And if plain HTTP ports are listed after HTTPS ports, the prior are used. It would be better to loop through the comma-separated list, skip redirected r ports, take the first plain IPv4 port, if present, else first plain IPv6 port (adding another loopback IP variable our end), else first HTTPS IPv4, else first HTTPS IPv6. But I am too tired today, and IPv4 incl. HTTPS-only should cover 99.5% of cases.

Another point I wanted to check is whether the /padd endpoints provides all info at once, so that we can skip the 2nd API request.