Allow customizing `BackupPollerDelayBlock` or disabling Backup LogPoller entirely for tests

[reductionista]

Previously, backupPollerBlockDelay was defined as a const in LogPoller and hard-coded to 100. Now, any value can be passed to the LogPoller constructor including 0 to disable Backup LogPoller entirely.

Also, the number of params passed to NewLogPoller() has been gradually getting out of control, so this is a good opportunity to move them into a logpoller.Opts struct. This simplifies many of the LogPoller test setups, allowing for the omission of default parameters and less duplication of code

The main motivation for this: some fairly sophisticated scale tests have been added for LogPoller under integration-tests, but presently they can give false negatives due to Backup Poller. (ie, most failures of regular LogPoller would go unnoticed because Backup LogPoller will automatically fix things as an emergency fallback. These tests don't look at timing issues, only correctness, so they cannot distinguish between a temporary failure for a short period and no failure). The only way we can obtain reliable results for these tests presently is to temporarily comment out the part that calls BackupPoller in the code. This adds a way to disable it in a test, so we can run them in an automated way and trust the results.

[github-actions[bot]]

I see that you haven't updated any CHANGELOG files. Would it make sense to do so?

[cl-sonarqube-production[bot]]

Quality Gate passed

Issues
0 New issues
1 Fixed issue
0 Accepted issues

Measures
0 Security Hotspots
98.1% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube