Fix polkadot-sdk CI failures (#2901)

* taplo

* markdown

* publish = false

* feature propagation

bridges/relays/finality/Cargo.toml

@@ -5,6 +5,7 @@ authors = ["Parity Technologies <admin@parity.io>"]
 edition = "2021"
 license = "GPL-3.0-or-later WITH Classpath-exception-2.0"
 description = "Finality proofs relay"
+publish = false
 
 [lints]
 workspace = true

bridges/relays/finality/README.md

@@ -3,7 +3,7 @@
 The finality relay is able to work with different finality engines. In the modern Substrate world they are GRANDPA
 and BEEFY. Let's talk about GRANDPA here, because BEEFY relay and bridge BEEFY pallet are in development.
 
-In general, the relay works as follows: it connects to the source and target chain. The source chain must have the 
+In general, the relay works as follows: it connects to the source and target chain. The source chain must have the
 [GRANDPA gadget](https://github.com/paritytech/finality-grandpa) running (so it can't be a parachain). The target
 chain must have the [bridge GRANDPA pallet](../../modules/grandpa/) deployed at its runtime. The relay subscribes
 to the GRANDPA finality notifications at the source chain and when the new justification is received, it is submitted
@@ -41,18 +41,20 @@ Finality relay provides several metrics. Metrics names depend on names of source
 shows metrics names for Rococo (source chain) to BridgeHubWestend (target chain) finality relay. For other
 chains, simply change chain names. So the metrics are:
 
-- `Rococo_to_BridgeHubWestend_Sync_best_source_block_number` - returns best finalized source chain (Rococo) block number, known
-  to the relay. If relay is running in [on-demand mode](../bin-substrate/src/cli/relay_headers_and_messages/), the
+- `Rococo_to_BridgeHubWestend_Sync_best_source_block_number` - returns best finalized source chain (Rococo) block
+  number, known to the relay.
+  If relay is running in [on-demand mode](../bin-substrate/src/cli/relay_headers_and_messages/), the
   number may not match (it may be far behind) the actual best finalized number;
 
-- `Rococo_to_BridgeHubWestend_Sync_best_source_at_target_block_number` - returns best finalized source chain (Rococo) block
-  number that is known to the bridge GRANDPA pallet at the target chain.
+- `Rococo_to_BridgeHubWestend_Sync_best_source_at_target_block_number` - returns best finalized source chain (Rococo)
+  block number that is known to the bridge GRANDPA pallet at the target chain.
 
-- `Rococo_to_BridgeHubWestend_Sync_is_source_and_source_at_target_using_different_forks` - if this metrics is set to `1`, then
-  the best source chain header, known to the target chain doesn't match the same-number-header at the source chain.
-  It means that the GRANDPA validators set has crafted the duplicate justification and it has been submitted to the
-  target chain. Normally (if majority of validators are honest and if you're running finality relay without large
-  breaks) this shall not happen and the metric will have `0` value.
+- `Rococo_to_BridgeHubWestend_Sync_is_source_and_source_at_target_using_different_forks` - if this metrics is set
+  to `1`, then  the best source chain header known to the target chain doesn't match the same-number-header
+  at the source chain. It means that the GRANDPA validators set has crafted the duplicate justification
+  and it has been submitted to the target chain.
+  Normally (if majority of validators are honest and if you're running finality relay without large breaks)
+  this shall not happen and the metric will have `0` value.
 
 If relay operates properly, you should see that the `Rococo_to_BridgeHubWestend_Sync_best_source_at_target_block_number`
 tries to reach the `Rococo_to_BridgeHubWestend_Sync_best_source_block_number`. And the latter one always increases.