test: rejoin test with slow catch-up

[mraszyk]

This PR adds a node rejoin test with a slow catch-up provoked by long DSM rounds:

• creating many canisters (100,000) - so that iterating over all canisters is slow;
• deploying a few "busy" canisters - so that executing those canisters is slow.

The test can be run using the following command:

ict t //rs/tests/message_routing:rejoin_test_long_rounds

Runbook:

• setup the testnet of 3f + 1 nodes with f = 4 (like on mainnet);
• pick a random node and install 4 "seed" canisters through it (the state sync test canister is used as "seed");
• create 100,000 canisters via the "seed" canisters (in parallel);
• deploy 8 "busy" canisters (universal canister with heartbeats executing 1.8B instructions);
• pick another random node and kill that node;
• wait for the subnet producing a CUP;
• start the killed node.

Success: the restarted node catches up w.r.t. its certified height and becomes healthy until the next CUP.

In the attached screenshot showing how much the restarted node is lagging behind, we see that the restarted node is catching up only very slowly at the moment

or (in another test run) does not catch up at all

[github-actions]

This pull request changes code owned by the Governance team. Therefore, make sure that
you have considered the following (for Governance-owned code):

1. Update unreleased_changelog.md (if there are behavior changes, even if they are
   non-breaking).

2. Are there BREAKING changes?

3. Is a data migration needed?

4. Security review?

How to Satisfy This Automatic Review

1. Go to the bottom of the pull request page.

2. Look for where it says this bot is requesting changes.

3. Click the three dots to the right.

4. Select "Dismiss review".

5. In the text entry box, respond to each of the numbered items in the previous
   section, declare one of the following:

• Done.

• $REASON_WHY_NO_NEED. E.g. for unreleased_changelog.md, "No
  canister behavior changes.", or for item 2, "Existing APIs
  behave as before.".

Brief Guide to "Externally Visible" Changes

"Externally visible behavior change" is very often due to some NEW canister API.

Changes to EXISTING APIs are more likely to be "breaking".

If these changes are breaking, make sure that clients know how to migrate, how to
maintain their continuity of operations.

If your changes are behind a feature flag, then, do NOT add entrie(s) to
unreleased_changelog.md in this PR! But rather, add entrie(s) later, in the PR
that enables these changes in production.

Reference(s)

For a more comprehensive checklist, see here.

GOVERNANCE_CHECKLIST_REMINDER_DEDUP

[github-actions]

This pull request modifies the IC-OS configuration types library (rs/ic_os/config_types/src/lib.rs).

Please ensure you have followed the Configuration Update Protocol guidelines——particularly if adding a new enum or enum variants:

Enum Variant Forward Compatibility Guidelines: If adding a new enum or new variants to an enum, ensure older versions can handle unknown variants gracefully by using #[serde(other)] on a fallback variant. See examples: GuestVMType::Unknown and Ipv6Config::Unknown.

To acknowledge this reminder and unblock the PR, dismiss this code review by:

• Going to the bottom of the pull request page
• Finding where this bot is requesting changes
• Clicking the three dots on the right
• Selecting "Dismiss review"

For complete guidelines, see the documentation at the top of rs/ic_os/config_types/src/lib.rs.

CONFIG_TYPES_COMPATIBILITY_REMINDER_DEDUP

No canister behavior changes.