[millheat] Binding is non-functional: the AbleCloud backend has been retired #21596

Expected Behavior

The Millheat binding signs in to the Mill cloud service and reports temperatures and heater state
for the homes, rooms and heaters on the account.

Current Behavior

The binding cannot reach its backend at all. Every account bridge fails with a connect timeout and
stays OFFLINE (COMMUNICATION_ERROR):

Error login: Error sending request to Millheat server:
java.net.SocketTimeoutException: Connect Timeout

The binding talks to Mill's old AbleCloud service, hardcoded in MillheatAccountHandler:

public static String authEndpoint = "https://eurouter.ablecloud.cn:9005/zc-account/v1/";
public static String serviceEndpoint = "https://eurouter.ablecloud.cn:9005/millService/v1/";

That host still resolves, but nothing is listening on it any more:

$ getent hosts eurouter.ablecloud.cn
52.57.161.207   eurouter.ablecloud.cn

$ for p in 80 443 9005; do timeout 8 bash -c "echo >/dev/tcp/eurouter.ablecloud.cn/$p" \
    && echo "  $p open" || echo "  $p dead"; done
  80 dead
  443 dead
  9005 dead

Mill has moved to a new service at https://api.millnorwaycloud.com, which is alive and answers
normally:

$ curl -s -o /dev/null -w '%{http_code}\n' -X POST \
    https://api.millnorwaycloud.com/customer/auth/sign-in \
    -H 'Content-Type: application/json' -d '{"login":"x","password":"y"}'
400

This affects every user of the binding, not a particular configuration. There is no workaround: no
combination of settings can make the binding reach a service that has been switched off.

Possible Solution

Rebuild the binding against the new API, which is documented at
http://mn-be-prod-documentation.s3-website.eu-central-1.amazonaws.com/#/ (OpenAPI 3.1).

Nothing of the old wire protocol survives. The old service used a SHA-1 signed
application/x-zc-object envelope with appId/appSecret; the new one is plain JSON REST with JWT
bearer tokens, a ten minute access token, a refresh token, and a documented limit of 2500 requests
per hour per customer.

The migration is unavoidably breaking for existing users. Homes, rooms and heaters are identified by
UUIDs on the new service, and the numeric identifiers issued by the old one have no equivalent, so
existing things cannot be migrated automatically and must be re-discovered. MAC addresses do carry
over, though the new service formats them with colons.

I have a working implementation and will open a PR against this issue. It has been running against a
real account and a production openHAB 5.2.1 instance, with sign-in, token refresh, polling,
discovery, room and device writes, and vacation mode all verified end to end.

Steps to Reproduce (for Bugs)

1. Add a Mill Heating API (millheat:account) thing with any valid Millheat username and password.
2. Wait for initialization to finish.
3. The bridge goes OFFLINE (COMMUNICATION_ERROR) with the connect timeout above, after the 30
   second HTTP timeout elapses.

Context

The binding is unusable. Existing installations that were working simply stopped, with no error that
points at the cause: the only symptom is a timeout against a host name that still resolves, so it
reads like a local network or firewall problem rather than a service that no longer exists.

There is currently no open issue recording this, so anyone hitting it has nothing to find when they
search.

Your Environment

• Version used: openHAB 5.2.1, Millheat binding 5.2.1; the endpoints are unchanged on main
• Environment name and version: OpenJDK 21.0.12
• Operating System and version: Debian GNU/Linux 13 (trixie), x86_64