Support having multiple crr locations configured in the queueProcessor

[Kerkesni]

QueueProcessor currently sets the destination host to the host of the last crr site in the bootstrap list, so when having multiple crr locations configured this will not work.

Issue: BB-662

[bert-e]

Hello kerkesni,

My role is to assist you with the merge of this
pull request. Please type @bert-e help to get information
on this process, or consult the user documentation.

Available options

name	description	privileged	authored
/after_pull_request	Wait for the given pull request id to be merged before continuing with the current one.
/bypass_author_approval	Bypass the pull request author's approval	⭐
/bypass_build_status	Bypass the build and test status	⭐
/bypass_commit_size	Bypass the check on the size of the changeset TBA	⭐
/bypass_incompatible_branch	Bypass the check on the source branch prefix	⭐
/bypass_jira_check	Bypass the Jira issue check	⭐
/bypass_peer_approval	Bypass the pull request peers' approval	⭐
/bypass_leader_approval	Bypass the pull request leaders' approval	⭐
/approve	Instruct Bert-E that the author has approved the pull request.		✍️
/create_pull_requests	Allow the creation of integration pull requests.
/create_integration_branches	Allow the creation of integration branches.
/no_octopus	Prevent Wall-E from doing any octopus merge and use multiple consecutive merge instead
/unanimity	Change review acceptance criteria from one reviewer at least to all reviewers
/wait	Instruct Bert-E not to run until further notice.

Available commands

name	description	privileged
/help	Print Bert-E's manual in the pull request.
/status	Print Bert-E's current status in the pull request TBA
/clear	Remove all comments from Bert-E from the history TBA
/retry	Re-start a fresh build TBA
/build	Re-start a fresh build TBA
/force_reset	Delete integration branches & pull requests, and restart merge process from the beginning.
/reset	Try to remove integration branches unless there are commits on them which do not appear on the source branch.

Status report is not available.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 73.18%. Comparing base (3b76ecc) to head (09fd95f).

Additional details and impacted files

Files with missing lines	Coverage Δ
...sions/replication/queueProcessor/QueueProcessor.js	73.41% <100.00%> (+0.44%)	⬆️

... and 2 files with indirect coverage changes

Components	Coverage Δ
Bucket Notification	75.37% <ø> (ø)
Core Library	79.62% <ø> (+0.20%)	⬆️
Ingestion	70.14% <ø> (ø)
Lifecycle	76.88% <ø> (ø)
Oplog Populator	85.06% <ø> (ø)
Replication	59.33% <100.00%> (+0.06%)	⬆️
Bucket Scanner	85.60% <ø> (ø)

@@                  Coverage Diff                   @@
##           improvement/BB-647    #2632      +/-   ##
======================================================
+ Coverage               73.09%   73.18%   +0.09%     
======================================================
  Files                     201      201              
  Lines                   13413    13415       +2     
======================================================
+ Hits                     9804     9818      +14     
+ Misses                   3599     3587      -12     
  Partials                   10       10              

Flag	Coverage Δ
api:retry	9.48% <0.00%> (-0.01%)	⬇️
api:routes	9.29% <0.00%> (-0.01%)	⬇️
bucket-scanner	85.60% <ø> (ø)
ft_test:queuepopulator	8.90% <0.00%> (-0.01%)	⬇️
ingestion	12.55% <0.00%> (-0.01%)	⬇️
lib	7.34% <0.00%> (-0.01%)	⬇️
lifecycle	18.72% <0.00%> (-0.01%)	⬇️
notification	1.06% <0.00%> (-0.01%)	⬇️
replication	18.78% <85.71%> (+0.09%)	⬆️
unit	48.86% <100.00%> (-0.04%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[bert-e]

Waiting for approval

The following approvals are needed before I can proceed with the merge:

• the author

• 2 peers

[williamlardier]

Changes LGTM (codecov still reports that all lines were not covered, yet the comment says the opposite...)

[Kerkesni]

The comments point to a previous run of codecov which is weird, but i added tests explicitly for those cases so they should be covered.

[francoisferrand]

for this I gather that the QueueProcessor only uses a single site from dest.bootstrapList : so should we not instead "select" the appropriate site's bootstrap list/endpoint(s) when building destConfig?

(since building every destConfig is done once, when loading the config, this would also allow to do it efficiently, without going searching linearly for every site)