configuration: Rename validation_upgrade_{frequency -> cooldown} (#4635)

This just renames a member of `HostConfiguration` from
validation_upgrade_frequency to -//-_cooldown.

As was already pointed out in #4460 the existing name is a misnomer, the
member actually represents a minimum time period between upgrades, which
is neatly expressed by a word cooldown.

I've been planning this rename already for some time and the term is
already used in paras module:

https://github.com/paritytech/polkadot/blob/1394b70d493a3b4bea7a9ae14af094081bc84456/runtime/parachains/src/paras.rs#L1568-L1574

polkadot/roadmap/implementers-guide/src/runtime/inclusion.md

@@ -85,7 +85,7 @@ All failed checks should lead to an unrecoverable error making the block invalid
   1. check that each candidate's `validation_data_hash` corresponds to a `PersistedValidationData` computed from the current state.
     > NOTE: With contextual execution in place, validation data will be obtained as of the state of the context block. However, only the state of the current block can be used for such a query.
   1. If the core assignment includes a specific collator, ensure the backed candidate is issued by that collator.
-  1. Ensure that any code upgrade scheduled by the candidate does not happen within `config.validation_upgrade_frequency` of `Paras::last_code_upgrade(para_id, true)`, if any, comparing against the value of `Paras::FutureCodeUpgrades` for the given para ID.
+  1. Ensure that any code upgrade scheduled by the candidate does not happen within `config.validation_upgrade_cooldown` of `Paras::last_code_upgrade(para_id, true)`, if any, comparing against the value of `Paras::FutureCodeUpgrades` for the given para ID.
   1. Check the collator's signature on the candidate data.
   1. check the backing of the candidate using the signatures and the bitfields, comparing against the validators assigned to the groups, fetched with the `group_validators` lookup.
   1. call `Ump::check_upward_messages(para, commitments.upward_messages)` to check that the upward messages are valid.

polkadot/roadmap/implementers-guide/src/runtime/paras.md

@@ -258,7 +258,7 @@ CodeByHash: map ValidationCodeHash => Option<ValidationCode>
 * `schedule_parachain_downgrade(ParaId)`: Schedule a parachain to be downgraded to a parathread.
 * `schedule_code_upgrade(ParaId, new_code, relay_parent: BlockNumber, HostConfiguration)`: Schedule a future code
   upgrade of the given parachain. In case the PVF pre-checking is disabled, or the new code is already present in the storage, the upgrade will be applied after inclusion of a block of the same parachain
-  executed in the context of a relay-chain block with number >= `relay_parent + config.validation_upgrade_delay`. If the upgrade is scheduled `UpgradeRestrictionSignal` is set and it will remain set until `relay_parent + config.validation_upgrade_frequency`.
+  executed in the context of a relay-chain block with number >= `relay_parent + config.validation_upgrade_delay`. If the upgrade is scheduled `UpgradeRestrictionSignal` is set and it will remain set until `relay_parent + config.validation_upgrade_cooldown`.
 In case the PVF pre-checking is enabled, or the new code is not already present in the storage, then the PVF pre-checking run will be scheduled for that validation code. If the pre-checking concludes with rejection, then the upgrade is canceled. Otherwise, after pre-checking is concluded the upgrade will be scheduled and be enacted as described above.
 * `note_new_head(ParaId, HeadData, BlockNumber)`: note that a para has progressed to a new head,
   where the new head was executed in the context of a relay-chain block with given number. This will