switch liquid designate to use prometheus queries for usage

[wagnerd3]

Please don't forget to merge the respective configuration change PR: sapcc/helm-charts#10970

This PR switches the 2 metrics which we derive for designate usage from the http API to Prometheus data, which is exported directly from the designate DB. This is to improve performance. In qa-de-1, on a random small project, we get a runtime of below 1s from Prometheus, while using the API results in 5s of runtime or more.

Opening this PR as draft for now, because the values of the zones metric between the old data and new data don't match when testing in qa-de-1. Here are the projects with their deviations that I just derived:

project_id	Prometheus	HTTP API
631a3518e93d436fbdf57525babe8606	2	4
c7201c32f08a4149ac6eb4ea4db4870d	44	16
e9141fb24eee4b3e9f25ae69cda31132	20	19
4caeee5bd86745f18233c07f51e7bd43	2	3
486ece4535a44096be6ae216139249f2	5	4
fdcf78492695421ab9767832a75d568a	8	5
3ea858d5d9374fbe820be72baf908da3	783	296
f272e220c75f4796b5bb6542649350fd	24	15
1b939a96561c49aca6b1002ec209df8b	1	3
d940aae3f8084f15a9b67de5b3b39720	149	7
ac694b5dd3bb4eb38e4e68bf0df73597	7	6
2735826666cc4a1789d267edce486de4	1	2
3af1c3304e3c494aa798767243b9e434	5	3
dff2385e8ad54617a240540693450bfe	(not present)	2
f0fb668325f746828d160f2ac3977275	(not present)	1

The small deviations in the magnitude of 1 or 2 are from scraping delays, I won't worry about it. But I cannot grasp the deviations on the other projects, as the values are mostly flat in Prometheus.

I found the deviations: The API seemingly filters out soft-deleted zones, which are naturally included in the database exports to Prometheus. When using the prometheus query with status!="DELETED" (see referenced PR!), we get to the following deviations:

Project ID	API (via Limes)	Prometheus	Difference
1b939a96561c49aca6b1002ec209df8b	3	1	-2
2735826666cc4a1789d267edce486de4	2	1	-1
3ea858d5d9374fbe820be72baf908da3	297	296	-1
4caeee5bd86745f18233c07f51e7bd43	3	2	-1
631a3518e93d436fbdf57525babe8606	4	2	-2
d940aae3f8084f15a9b67de5b3b39720	7	6	-1
e9141fb24eee4b3e9f25ae69cda31132	19	17	-2

They are reasonably small so that I would assume they come from Limes scraping delays.

Checklist:

• If this PR is about a plugin, I tested the plugin against an OpenStack cluster.
• I updated the documentation to describe the semantical or interface changes I introduced.

[github-actions]

Merging this branch will not change overall coverage

Impacted Packages	Coverage Δ	🤖
github.com/sapcc/limes	0.00% (ø)
github.com/sapcc/limes/internal/liquids/designate	0.00% (ø)

---

Coverage by file

Changed files (no unit tests)

Changed File	Coverage Δ	Total	Covered	Missed	🤖
github.com/sapcc/limes/internal/liquids/designate/client.go	0.00% (ø)	0	0	0
github.com/sapcc/limes/internal/liquids/designate/liquid.go	0.00% (ø)	0	0	0
github.com/sapcc/limes/main.go	0.00% (ø)	0	0	0

Please note that the "Total", "Covered", and "Missed" counts above refer to code statements instead of lines of code. The value in brackets refers to the test coverage of that file in the old version of the code.