[mle] improve router and leader post reset link request timings and attempts (#12022)

In order to facilitate a well-staged post reset process for a larger
size link, it is important to consider the timing of devices returning
to the link.

With the changes in this PR, that timing will be as follows:
1. The leader and routers will begin sending link request messages in
   an attempt to reattach to the previous partition.
2. Both the leader and routers will have 4 attempts to reconnect,
   afterwords falling back to attach any.
3. The leader here is given a 2s retry window (jittered 10% either
   way), for a worst-case (tightest timing vs routers) of 4x2.2s =
   8.8s before starting attachment.
4. The routers here are given the normal 5s multicast retx delay with
   the same 10% jitter, resulting in a tightest timing (shortest) of
   4x4.5s = 18s
5. For this analysis, the jitter during the attach process is ignored
   because it will not be particularly significant, so we assume both
   flow through a nominal failed attachment of 2x0.75s (routers) +
   4x1.25s (reeds) = 6.5s
6. This means that the previous leader will start the new partition
   around 15.3s after starting.
7. The former routers would fall back to starting a new partition on
   their own at 24.5s after reset.

This timing leaves 9.2s of leeway (greater than the length of the full
attachment process) for the routers to get parent responses from the
old leader which has started the new partition and attach instead of
starting their own partitions.

This also leaves sufficient time between the router attachment and
children timing out of their role restoration process to attach to
their former parents.

Additionally, 4 attempts should be more than sufficient with this
timing to successfully reattach to a partition that did not also
reset. If a link request sent in this period is not accepted, then the
old partition can be safely assumed to be gone, or removed links to
the reset device.

Routers with children and the leader will also benefit in
single-device reset cases here because they are able to rejoin more
quickly. Only routers with very few/no children are slowed down in
re-attachment by 5s.

tests/scripts/thread-cert/config.py

@@ -122,9 +122,10 @@ SECURITY_POLICY = [672, 'onrc']
 LEADER_STARTUP_DELAY = 12
 ROUTER_STARTUP_DELAY = 10
 # See logic of RouterRoleRestorer
-# ((kMaxTxCount=6) - 1) * 1.1 * (kMulticastRetxDelay=5) + 2 + ROUTER_STARTUP_DELAY
-ROUTER_RESTORE_DELAY = 40
-LEADER_REBOOT_DELAY = 40
+# (MLE_MAX_RESTORING_TRANSMISSION_COUNT - 1) * 1.1 * (kMulticastRetxDelay=5s) + 2s + ROUTER_STARTUP_DELAY
+ROUTER_RESTORE_DELAY = 29
+# (MLE_MAX_RESTORING_TRANSMISSION_COUNT - 1) * 1.1 * (kLinkRequestTimeout=2s) + 2s + LEADER_STARTUP_DELAY
+LEADER_REBOOT_DELAY = 21
 ED_STARTUP_DELAY = 5
 BORDER_ROUTER_STARTUP_DELAY = 20
 MAX_NEIGHBOR_AGE = 100
@@ -153,11 +154,11 @@ PACKET_VERIFICATION_NONE = 0
 PACKET_VERIFICATION_DEFAULT = 1
 PACKET_VERIFICATION_TREL = 2
 
-# After leader reset it may retransmit link request 6 times with max 5.5s interval
-LEADER_RESET_DELAY = 41
-# After router reset it may retransmit link request 3 times with max 5.5s interval
-ROUTER_RESET_DELAY = 23
-MLE_MAX_CRITICAL_TRANSMISSION_COUNT = 6
+# After leader reset it may retransmit link request 4 times with max 2.2s interval
+LEADER_RESET_DELAY = 17
+# After router reset it may retransmit link request 4 times with max 5.5s interval
+ROUTER_RESET_DELAY = 30
+MLE_MAX_RESTORING_TRANSMISSION_COUNT = 4
 MLE_MAX_TRANSMISSION_COUNT = 3