Description

When testing VEX support, I noticed Scanner V4 DB's CPU was periodically active. Looking at the Scanner V4 Matcher logs, I realized that the GC is run upon every successful update cycle, even if that means there was nothing updated (success in this case just means there were no errors).

This PR now limits the GC to only run upon update cycles that not only don't error out, but also actually update something.

It's not perfect, as it's still possible a Matcher replica that does nothing towards updating the vulnerabilities runs the GC[1], but that's ok, as it's not nearly as common as this scenario.

[1] Imagine there are two Matcher replicas and there are new vulnerability updates. It is possible (highly unlikely, though) that only one of the Matchers handles all the updates when reading the "multi-bundle". But, if this were to happen and somehow both Matchers were able to get the GC lock without any kind of contention, then both Matchers will run a GC cycle. This is highly unlikely, so it's ok to ignore. We should care more about the way more common case that there are no vulnerability updates, and we still run the GC for no real reason.

I also found we needlessly require a pgxpool when creating a vuln updater, so I remove that here, too

User-facing documentation

• CHANGELOG update is not needed
• documentation PR is not needed

Testing and quality

• the change is production ready: the change is GA or otherwise the functionality is gated by a feature flag
• CI results are inspected

Automated testing

• modified existing tests

How I validated my change

Here is what I saw in my VEX PR testing:

Here is what I see now:

Note the scale of the graph. This shows activity every few hours, instead of every few minutes