HaProxy Certbots make certificate challange possible without stopping…

… haproxy

Improve the haconfig file

Better readability
Better fallback use

Fixed docs url with the new one

Fix wrong variable being used when fetching from aggregate

Fix reserved space calculation

Make the diagnostic example code compatible with pydantic 1 and 2

so it doesn't fail in the ci

Fix: Increase Aleph SDK dependency to the new version 2.0.0

Allow /56 subnet for ipv6 pool (#761)

Needed for some crn

Fix DiagnosticVM, force ipv4 connexion on /internet check (#760)

This fix issue reported by node owner where if they enable a ipv6 and it's not working, it also break the diagnostic /internet check

Jira ticket: ALEPH-419

CRN with bad IPv6 config were having bad metrics, as /status/check/fastapi was too slow which looking further into it , came from /vm/63faf8b5db1cf8d965e6a464a0cb8062af8e7df131729e48738342d956f29ace/internet always taking 5 seconds, even if it ultimately returned positive resurlt.

Coincidentally 5 seconds is the timeout configured in check_url inside the diagnostic vm (example_fastapi/main.py)

To reproduce issue
set the DNS server via environment variable
```env
ALEPH_VM_DNS_NAMESERVERS = '[2001:41d0:3:163::1, 9.9.9.9]'
```
that ipv6 server being unreachable
and set ip pool to default one
```
ALEPH_VM_IPV6_ADDRESS_POOL = fc00:1:2:3::/64
```

Solution:

Further analysis is that the diagnostic VM tried to connect to the ipv6 DNS server, did timout after  5 seconds then proceeded normally with the ipv4 DNS

Put the ipv4 DNS server BEFORE the ipv6 one.
Also disable the ipv6 server if ipv6 is not enabled for the VM. That modification was done for instances but failed to be reproduced for programs