safely delete unused values of the Config enum

[DaanHoogland]

the remaining unused values after refactorring the enumeration values need to be removed. This will probably have to be a DB upgrade path.

[DaanHoogland]

Found a related case while writing wiring tests (issue #10752): ManagementServer.Ovm3HeartBeatTimeout/Ovm3HeartBeatInterval (server/src/main/java/com/cloud/server/ManagementServer.java:184-188) have zero consumers anywhere in the codebase — Ovm3Discoverer never populates ovm3.heartbeat.timeout/ovm3.heartbeat.interval into the params map that Ovm3Configuration.java:112,115 reads (unlike the XenServer equivalents, which DiscovererBase.buildConfigParams() does wire through correctly). Only Ovm3ConfigurationTest.java sets these two keys manually in its test params map, masking the fact that production code never populates them. This predates the #10752 migration entirely — the same two dead entries existed in the old Config enum under the same names — so it's pre-existing dead wiring, not something introduced by this PR. Since these two ConfigKeys have no live consumer, they're also candidates for the safe-deletion sweep this issue tracks (in addition to the enum-side dead values already in scope).

[DaanHoogland]

Two more dead ConfigKeys found while continuing the ManagementServer wiring batch: ManagementServer.LinkLocalIpNums (linkLocalIp.nums) and ManagementServer.DetailBatchQuerySize (detail.batch.query.size) are declared and returned from ManagementServerImpl.getConfigKeys(), but neither has a single .value() (or any other) consumer anywhere in the repo. Both existed under the same names in the old Config enum before the #10752 migration, so — like the Ovm3 heartbeat pair above — this is pre-existing dead wiring, not something this PR introduced. Adding to the same bucket for the safe-deletion sweep.