remove redundant/diverging hardcoded defaults in parseInt/parseLong wrapping ConfigKey reads

[DaanHoogland]

Many call sites read a ConfigKey via the raw DAO and wrap the result in NumbersUtil.parseInt(value, someLiteral) / NumbersUtil.parseLong(...) / Integer.parseInt(...), supplying a hardcoded fallback even though the ConfigKey already carries its own default via .defaultValue() (and .value() applies that default automatically when no DB row exists). Most of the time the literal happens to match the ConfigKey's declared default, so it's just redundant. But it doesn't always match — which is a latent bug, not just noise, since the two numbers silently diverge depending on which code path executes.

Found during the .value() migration pass (issue #10752):

• DeploymentPlanningManagerImpl.java — HostReservationReleasePeriod: ConfigKey default is "300000", but the field's Java-level initializer is 60L * 60L * 1000L (3,600,000), and the code only falls back to the ConfigKey default when the persisted value is <= 0 — not when the row is simply missing (null), in which case it silently keeps 3,600,000 instead of 300,000.
• StorageCacheManagerImpl.java — ExpungeWorkers: ConfigKey default is "1", but the read is NumbersUtil.parseInt(configDao.getValue(...), 10) — a hardcoded fallback of 10 vs. the registered default of 1.
• UcsManagerImpl.java — UCSSyncBladeInterval: ConfigKey default is "3600", but a leftover catch (NumberFormatException e) { syncBladeInterval = 600; } uses 600. Low risk in practice since .value() no longer throws on parse, but the mismatched literal is still latent debt.

These three were left un-migrated to .value() specifically because of this discrepancy — picking either number without a decision would silently change fresh-install/edge-case behavior. Worth a repo-wide sweep for the same parseInt/parseLong-with-hardcoded-default pattern, since these three were only found incidentally while migrating unrelated call sites, not through an exhaustive search.

[DaanHoogland]

Related variant found while scoping ManagementServer wiring tests: ManagementServerImpl.configure() has EventPurgeDelay/EventPurgeInterval ConfigKeys defined but the read site still goes through a raw _configDao.getConfiguration() map lookup by literal string (never migrated to .value() at all), with the same kind of diverging default (hardcoded fallback 0 vs. registered default 15) as the cases above. Filed separately as #13898 since it's a different mechanical shape (raw map lookup, not a parseInt/parseLong wrapper around an already-migrated .value() call), but flagging here since the underlying risk — silently divergent defaults — is the same.

[DaanHoogland]

Another variant found while writing wiring tests for ApiRateLimitServiceImpl (plugins/api/rate-limit/src/main/java/org/apache/cloudstack/ratelimit/ApiRateLimitServiceImpl.java:79-113): the read site was never migrated to .value() at all (still raw _configDao.getValue(key.key()), tracked separately under #13898), and its own fallback shape is if (raw != null) { field = parse(raw); } — i.e. the class keeps its own hardcoded Java field default whenever the config row is missing, rather than ever consulting the ConfigKey's registered default. Two concrete divergences:

• maxAllowed field defaults to 30; ManagementServer.ApiLimitMax's registered default is "25".
• maxElements (ehcache size) defaults to 10000; ApiRateLimitService.ApiLimitCacheSize's registered default is "50000".

This one was actually already known/deliberately deferred earlier in the #10752 .value()-replacement pass, specifically because ApiRateLimitTest mocks ApiLimitEnabled="true" (opposite of the registered `"false"" default) purely so its functional tests have rate limiting turned on — flagging the two numeric ones here since they hadn't been written down anywhere yet.

[DaanHoogland]

Worth calling out explicitly: the ApiRateLimitServiceImpl case noted above is actually a third structural shape of this same divergent-default risk, alongside the issue's original parseInt/parseLong-wrapping shape and the raw-config-map shape from #13898:

• parseInt/parseLong wrapping (this issue's original scope): NumbersUtil.parseInt(configDao.getValue(key.key()), literalDefault) — the literal fallback silently diverges from the ConfigKey's registered default.
• raw map / getValue with no fallback at all: e.g. EventPurgeDelay/EventPurgeInterval — the field simply keeps whatever it was already initialized to when the row is missing.
• if-null-skip (the ApiRateLimitServiceImpl shape): if (raw != null) { field = parse(raw); } with no else — functionally identical to the previous shape (field keeps its own hardcoded default when unset) but written as a guarded assignment rather than a wrapped parse call, so it doesn't show up in a grep for parseInt/parseLong.

All three converge on the same root cause (a raw retrieval path that never consults ConfigKey.defaultValue()), but need different greps to find, which is why a repo-wide sweep should probably search for all three shapes rather than just the parseInt/parseLong one this issue was originally filed against.