Fix #4743 which allows
us to remove the defensive limit on pov size in Cumulus after relay
chain gets upgraded with these changes. Also add unit test to ensure
`CheckWeight` - `StorageWeightReclaim` integration works.

TODO:
- [x] PRDoc
- [x] Add a len to all the other tests in storage weight reclaim and
call `CheckWeight::pre_dispatch`

---------

Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>

Clobbers the `stable` branch with the `audited` tag as described in the
[RELEASE.md](https://github.com/paritytech/polkadot-sdk/blob/master/docs/RELEASE.md#clobbering).

Example of the `staging_stable` branch now after force-pushing the
`staging_audited` tag for a few times. The `staging_` prefix has now
been removed and should be ready for normal use.
The only trigger is currently manual, but can easily be set to three
months.
![Screenshot 2024-06-13 at 00 47
43](https://github.com/paritytech/polkadot-sdk/assets/10380170/97e070ad-ce2d-4504-83a0-ad6717b6e73e)

---------

Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>

Closes: #4801

@andreclaro I hope this makes it more clear from the docs directly.

remove unnecessary words in comments.

* fix rotko's pcollectives bootnode
* Update people-kusama.json
* Add Dwellir People Kusama bootnode
* add Gatotech bootnodes to `people-kusama`
* Add Dwellir People Kusama bootnode
* Update Amforc bootnodes for Kusama and Polkadot (#4668)

---------

Co-authored-by: RadiumBlock <info@radiumblock.com>
Co-authored-by: Jonathan Udd <jonathan@dwellir.com>
Co-authored-by: Milos Kriz <milos_kriz@hotmail.com>
Co-authored-by: tugy <33746108+tugytur@users.noreply.github.com>
Co-authored-by: Kutsal Kaan Bilgin <kutsalbilgin@gmail.com>
Co-authored-by: Petr Mensik <petr.mensik1@gmail.com>
Co-authored-by: Tommi <tommi@romeblockchain>

The crate `sc-cli` otherwise enables the `rocksdb` feature.

this pr is a part of #3326

---------

Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com>
Co-authored-by: Bastian Köcher <git@kchr.de>

Update parachain template pallet based on polkadot sdk docs

@kianenigma

---------

Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com>

Glutton currently is useful mostly for stress testing relay chain
validators. It is unusable for testing the collator networking and block
announcement and import scenarios. This PR resolves that by improving
glutton pallet to also buff up the blocks, up to the runtime configured
`BlockLength`.

### How it works
Includes an additional inherent in each parachain block. The `garbage`
argument passed to the inherent is filled with trash data. It's size is
computed by applying the newly introduced `block_length` percentage to
the maximum block length for mandatory dispatch class. After
#4765 is merged, the
length of inherent extrinsic will be added to the total block proof
size.

The remaining weight is burnt in `on_idle` as configured by the
`storage` percentage parameter.


TODO:
- [x] PRDoc
- [x] Readme update
- [x] Add tests

---------

Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>

# ISSUE
- Link to the issue:
#3800
# Deliverables
- [x] remove deprecated calls;
(d579b67)
- [x] set explicit coded indexes for Error and Event enums, remove
unused variants and keep the same indexes for the rest;
(d579b67)
- [x] remove unused Config's type parameters;
(d579b67)
- [x] remove irrelevant tests and adopt relevant using old api;
(d579b67)
- [x] remove benchmarks for removed calls;
(1a3d5f1)
- [x] prdoc
(d579b67)
- [x] remove deprecated methods from the `treasury/README.md` and add
up-to-date dispatchable functions documentation
(d579b67)
- [x] remove deprecated weight functions
(8f74134)
> ### Separated to other issues
> - [ ] remove storage items like Proposals and ProposalCount, that are
not used anymore

Adjust all treasury pallet instances within polkadot-sdk
- [x] `pallet_bounty`, `tip`, `child_bounties`:
openguild-labs#3
- [x] Remove deprecated treasury weight functions used in Westend and
Rococo runtime `collective-westend`, `collective-rococo`

Add migration for westend and rococo to clean the data from removed
storage items
- [ ] #3828
# Test Outcomes
Successful tests by running `cargo test --features runtime-benchmarks`
```
running 38 tests
test tests::__construct_runtime_integrity_test::runtime_integrity_tests ... ok
test benchmarking::benchmarks::bench_check_status ... ok
test benchmarking::benchmarks::bench_payout ... ok
test benchmarking::benchmarks::bench_spend_local ... ok
test tests::accepted_spend_proposal_enacted_on_spend_period ... ok
test benchmarking::benchmarks::bench_spend ... ok
test tests::accepted_spend_proposal_ignored_outside_spend_period ... ok
test benchmarking::benchmarks::bench_void_spend ... ok
test benchmarking::benchmarks::bench_remove_approval ... ok
test tests::genesis_funding_works ... ok
test tests::genesis_config_works ... ok
test tests::inexistent_account_works ... ok
test tests::minting_works ... ok
test tests::check_status_works ... ok
test tests::payout_retry_works ... ok
test tests::pot_underflow_should_not_diminish ... ok
test tests::remove_already_removed_approval_fails ... ok
test tests::spend_local_origin_permissioning_works ... ok
test tests::spend_valid_from_works ... ok
test tests::spend_expires ... ok
test tests::spend_works ... ok
test tests::test_genesis_config_builds ... ok
test tests::spend_payout_works ... ok
test tests::spend_local_origin_works ... ok
test tests::spend_origin_works ... ok
test tests::spending_local_in_batch_respects_max_total ... ok
test tests::spending_in_batch_respects_max_total ... ok
test tests::try_state_proposals_invariant_2_works ... ok
test tests::try_state_proposals_invariant_1_works ... ok
test tests::try_state_spends_invariant_2_works ... ok
test tests::try_state_spends_invariant_1_works ... ok
test tests::treasury_account_doesnt_get_deleted ... ok
test tests::try_state_spends_invariant_3_works ... ok
test tests::unused_pot_should_diminish ... ok
test tests::void_spend_works ... ok
test tests::try_state_proposals_invariant_3_works ... ok
test tests::max_approvals_limited ... ok
test benchmarking::benchmarks::bench_on_initialize_proposals ... ok

test result: ok. 38 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.08s

   Doc-tests pallet_treasury

running 2 tests
test substrate/frame/treasury/src/lib.rs - (line 52) ... ignored
test substrate/frame/treasury/src/lib.rs - (line 79) ... ignored

test result: ok. 0 passed; 0 failed; 2 ignored; 0 measured; 0 filtered out; finished in 0.00s
```

polkadot address: 19nSqFQorfF2HxD3oBzWM3oCh4SaCRKWt1yvmgaPYGCo71J

# ISSUE
- Link to issue: #3617
# Description
> Any set parameter / update config call with multiple arguments should
have each argument to be an Option field. Please put this to some best
practice document. This allows new update config call does not need to
duplicate the fields that does not need to update. It also makes
concurrent votes of update call possible, otherwise there will be race
condition. It also helps with review such proposal otherwise reviewers
need to check the other fields should remain the same.
- [ ] Concurrent call & race condition testing
- [x] Each argument of the `ParamsType` is an `Option` field. Introduce
through
```rust
pub type PartialParamsOf<T, I> =
		ParamsType<Option<<T as Config<I>>::Balance>, Option<BlockNumberFor<T>>, RANK_COUNT>;
```
# Outcome
```rust
let params = ParamsType {
	active_salary: [None; 9],
	passive_salary: [None; 9],
	demotion_period: [None, Some(10), None, None, None, None, None, None, None],
	min_promotion_period: [None; 9],
	offboard_timeout: Some(1),
};
CoreFellowship::set_partial_params(signed(2), Box::new(params.clone())),
```
Test coverage
```diff
running 21 tests
test tests::unit::__construct_runtime_integrity_test::runtime_integrity_tests ... ok
test tests::unit::basic_stuff ... ok
test tests::integration::test_genesis_config_builds ... ok
test tests::integration::__construct_runtime_integrity_test::runtime_integrity_tests ... ok
test tests::unit::auto_demote_offboard_works ... ok
test tests::unit::auto_demote_works ... ok
test tests::unit::get_salary_works ... ok
test tests::unit::active_changing_get_salary_works ... ok
test tests::integration::swap_bad_noops ... ok
test tests::unit::promote_postpones_auto_demote ... ok
test tests::unit::infinite_demotion_period_works ... ok
test tests::unit::proof_postpones_auto_demote ... ok
test tests::unit::induct_works ... ok
test tests::unit::set_params_works ... ok
test tests::unit::test_genesis_config_builds ... ok
test tests::unit::offboard_works ... ok
test tests::unit::sync_works ... ok
+ test tests::unit::set_partial_params_works ... ok
test tests::integration::swap_exhaustive_works ... ok
test tests::unit::promote_works ... ok
test tests::integration::swap_simple_works ... ok

test result: ok. 21 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.01s

   Doc-tests pallet_core_fellowship

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
```

polkadot address: 19nSqFQorfF2HxD3oBzWM3oCh4SaCRKWt1yvmgaPYGCo71J

---------

Co-authored-by: Dónal Murray <donalm@seadanda.dev>
Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
Co-authored-by: Bastian Köcher <git@kchr.de>

This unifies the logic between `CallExecutor` and `Client` when it comes
to fetching the `code` for a given block. The actual `code` depends on
potential overrides/substitutes.

Besides that it changes the logic in the lookahead collator on which
`ValidationCodeHash` it sends to the validator alongside the `POV`. We
are now sending the code hash as found on the relay chain. This is done
as the local node could run with an override which is compatible to the
validation code on the relay chain, but has a different hash.

remove redundant words in comments.

Co-authored-by: Bastian Köcher <git@kchr.de>
Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>

Migrated commands individually to work as GitHub actions with a
[`workflow_dispatch`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_dispatch)
event.

This will not disable the command-bot yet, but it's the first step
before disabling it.

### Commands migrated
- [x] bench-all
- [x] bench-overhead
- [x] bench
- [x] fmt
- [x] update-ui

Also created an action that will inform users about the new
documentation when they comment `bot`.

### Created documentation 
Created a detailed documentation on how to use this action. Found the
documentation
[here](https://github.com/paritytech/polkadot-sdk/blob/bullrich/cmd-action/.github/commands-readme.md).

---------

Co-authored-by: Alexander Samusev <41779041+alvicsam@users.noreply.github.com>
Co-authored-by: Przemek Rzad <przemek@parity.io>

Implements most of
#1797

Core sharing (two parachains or more marachains scheduled on the same
core with the same `PartsOf57600` value) was not working correctly. The
expected behaviour is to have Backed and Included event in each block
for the paras sharing the core and the paras should take turns. E.g. for
two cores we expect: Backed(a); Included(a)+Backed(b);
Included(b)+Backed(a); etc. Instead of this each block contains just one
event and there are a lot of gaps (blocks w/o events) during the
session.

Core sharing should also work when collators are building collations
ahead of time

TODOs:

- [x] Add a zombienet test verifying that the behaviour mentioned above
works.
- [x] prdoc

---------

Co-authored-by: alindima <alin@parity.io>

`ValueEnum` is apparently not using the `from_str`...

Closes: #4828

Previous attempt paritytech/substrate#14314

Close #4443 

Ideally, we should move /health and /health/readiness to the prometheus
server but because it's was quite easy to implement on the RPC server
and that RPC server already exposes /health.

Manual tests on a polkadot node syncing:

```bash
➜ polkadot-sdk (na-fix-4443) ✗ curl -v localhost:9944/health
* Host localhost:9944 was resolved.
* IPv6: ::1
* IPv4: 127.0.0.1
*   Trying [::1]:9944...
* connect to ::1 port 9944 from ::1 port 55024 failed: Connection refused
*   Trying 127.0.0.1:9944...
* Connected to localhost (127.0.0.1) port 9944
> GET /health HTTP/1.1
> Host: localhost:9944
> User-Agent: curl/8.5.0
> Accept: */*
>
< HTTP/1.1 200 OK
< content-type: application/json; charset=utf-8
< content-length: 53
< date: Fri, 14 Jun 2024 16:12:23 GMT
<
* Connection #0 to host localhost left intact
{"peers":0,"isSyncing":false,"shouldHavePeers":false}%
➜ polkadot-sdk (na-fix-4443) ✗ curl -v localhost:9944/health/readiness
* Host localhost:9944 was resolved.
* IPv6: ::1
* IPv4: 127.0.0.1
*   Trying [::1]:9944...
* connect to ::1 port 9944 from ::1 port 54328 failed: Connection refused
*   Trying 127.0.0.1:9944...
* Connected to localhost (127.0.0.1) port 9944
> GET /health/readiness HTTP/1.1
> Host: localhost:9944
> User-Agent: curl/8.5.0
> Accept: */*
>
< HTTP/1.1 500 Internal Server Error
< content-type: application/json; charset=utf-8
< content-length: 0
< date: Fri, 14 Jun 2024 16:12:36 GMT
<
* Connection #0 to host localhost left intact
```

//cc @BulatSaif you may be interested in this..

---------

Co-authored-by: Bastian Köcher <git@kchr.de>

Bumps
[curve25519-dalek](https://github.com/dalek-cryptography/curve25519-dalek)
from 4.1.2 to 4.1.3.
<details>
<summary>Commits</summary>
<ul>
<li><a
href="https://github.com/dalek-cryptography/curve25519-dalek/commit/5312a0311ec40df95be953eacfa8a11b9a34bc54"><code>5312a03</code></a>
curve: Bump version to 4.1.3 (<a
href="https://redirect.github.com/dalek-cryptography/curve25519-dalek/issues/660">#660</a>)</li>
<li><a
href="https://github.com/dalek-cryptography/curve25519-dalek/commit/b4f9e4df92a4689fb59e312a21f940ba06ba7013"><code>b4f9e4d</code></a>
SECURITY: fix timing variability in backend/serial/u32/scalar.rs (<a
href="https://redirect.github.com/dalek-cryptography/curve25519-dalek/issues/661">#661</a>)</li>
<li><a
href="https://github.com/dalek-cryptography/curve25519-dalek/commit/415892acf1cdf9161bd6a4c99bc2f4cb8fae5e6a"><code>415892a</code></a>
SECURITY: fix timing variability in backend/serial/u64/scalar.rs (<a
href="https://redirect.github.com/dalek-cryptography/curve25519-dalek/issues/659">#659</a>)</li>
<li><a
href="https://github.com/dalek-cryptography/curve25519-dalek/commit/56bf398d0caed63ef1d1edfbd35eb5335132aba2"><code>56bf398</code></a>
Updates license field to valid SPDX format (<a
href="https://redirect.github.com/dalek-cryptography/curve25519-dalek/issues/647">#647</a>)</li>
<li><a
href="https://github.com/dalek-cryptography/curve25519-dalek/commit/9252fa5c0d09054fed4ac4d649e63c40fad7abaf"><code>9252fa5</code></a>
Mitigate check-cfg until MSRV 1.77 (<a
href="https://redirect.github.com/dalek-cryptography/curve25519-dalek/issues/652">#652</a>)</li>
<li><a
href="https://github.com/dalek-cryptography/curve25519-dalek/commit/1efe6a93b176c4389b78e81e52b2cf85d728aac6"><code>1efe6a9</code></a>
Fix a minor typo in signing.rs (<a
href="https://redirect.github.com/dalek-cryptography/curve25519-dalek/issues/649">#649</a>)</li>
<li><a
href="https://github.com/dalek-cryptography/curve25519-dalek/commit/cc3421a22fa7ee1f557cbe9243b450da53bbe962"><code>cc3421a</code></a>
Indicate that the rand_core feature is required (<a
href="https://redirect.github.com/dalek-cryptography/curve25519-dalek/issues/641">#641</a>)</li>
<li><a
href="https://github.com/dalek-cryptography/curve25519-dalek/commit/858c4ca8ae03d33fe8b71b4504c4d3f5ff5b45c0"><code>858c4ca</code></a>
Address new nightly clippy unnecessary qualifications (<a
href="https://redirect.github.com/dalek-cryptography/curve25519-dalek/issues/639">#639</a>)</li>
<li><a
href="https://github.com/dalek-cryptography/curve25519-dalek/commit/31ccb6705067d68782cb135e23c79b640a6a06ee"><code>31ccb67</code></a>
Remove platforms in favor using CARGO_CFG_TARGET_POINTER_WIDTH (<a
href="https://redirect.github.com/dalek-cryptography/curve25519-dalek/issues/636">#636</a>)</li>
<li><a
href="https://github.com/dalek-cryptography/curve25519-dalek/commit/19c7f4a5d5e577adc9cc65a837abef9ed7ebf0a4"><code>19c7f4a</code></a>
Fix new nightly redundant import lint warns (<a
href="https://redirect.github.com/dalek-cryptography/curve25519-dalek/issues/638">#638</a>)</li>
<li>Additional commits viewable in <a
href="https://github.com/dalek-cryptography/curve25519-dalek/compare/curve25519-4.1.2...curve25519-4.1.3">compare
view</a></li>
</ul>
</details>
<br />


[![Dependabot compatibility
score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=curve25519-dalek&package-manager=cargo&previous-version=4.1.2&new-version=4.1.3)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)

Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.

[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)

---

<details>
<summary>Dependabot commands and options</summary>
<br />

You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
You can disable automated security fix PRs for this repo from the
[Security Alerts
page](https://github.com/paritytech/polkadot-sdk/network/alerts).

</details>

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

…erate_hex_encoded_call (#4825)

Bumps [ws](https://github.com/websockets/ws) from 8.16.0 to 8.17.1.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/websockets/ws/releases">ws's
releases</a>.</em></p>
<blockquote>
<h2>8.17.1</h2>
<h1>Bug fixes</h1>
<ul>
<li>Fixed a DoS vulnerability (<a
href="https://redirect.github.com/websockets/ws/issues/2231">#2231</a>).</li>
</ul>
<p>A request with a number of headers exceeding
the[<code>server.maxHeadersCount</code>][]
threshold could be used to crash a ws server.</p>
<pre lang="js"><code>const http = require('http');
const WebSocket = require('ws');
<p>const wss = new WebSocket.Server({ port: 0 }, function () {
const chars =
&quot;!#$%&amp;'*+-.0123456789abcdefghijklmnopqrstuvwxyz^_`|~&quot;.split('');
const headers = {};
let count = 0;</p>
<p>for (let i = 0; i &lt; chars.length; i++) {
if (count === 2000) break;</p>
<pre><code>for (let j = 0; j &amp;lt; chars.length; j++) {
  const key = chars[i] + chars[j];
  headers[key] = 'x';

  if (++count === 2000) break;
}
</code></pre>
<p>}</p>
<p>headers.Connection = 'Upgrade';
headers.Upgrade = 'websocket';
headers['Sec-WebSocket-Key'] = 'dGhlIHNhbXBsZSBub25jZQ==';
headers['Sec-WebSocket-Version'] = '13';</p>
<p>const request = http.request({
headers: headers,
host: '127.0.0.1',
port: wss.address().port
});</p>
<p>request.end();
});
</code></pre></p>
<p>The vulnerability was reported by <a
href="https://github.com/rrlapointe">Ryan LaPointe</a> in <a
href="https://redirect.github.com/websockets/ws/issues/2230">websockets/ws#2230</a>.</p>
<p>In vulnerable versions of ws, the issue can be mitigated in the
following ways:</p>
<ol>
<li>Reduce the maximum allowed length of the request headers using the
[<code>--max-http-header-size=size</code>][] and/or the
[<code>maxHeaderSize</code>][] options so
that no more headers than the <code>server.maxHeadersCount</code> limit
can be sent.</li>
</ol>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="https://github.com/websockets/ws/commit/3c56601092872f7d7566989f0e379271afd0e4a1"><code>3c56601</code></a>
[dist] 8.17.1</li>
<li><a
href="https://github.com/websockets/ws/commit/e55e5106f10fcbaac37cfa89759e4cc0d073a52c"><code>e55e510</code></a>
[security] Fix crash when the Upgrade header cannot be read (<a
href="https://redirect.github.com/websockets/ws/issues/2231">#2231</a>)</li>
<li><a
href="https://github.com/websockets/ws/commit/6a00029edd924499f892aed8003cef1fa724cfe5"><code>6a00029</code></a>
[test] Increase code coverage</li>
<li><a
href="https://github.com/websockets/ws/commit/ddfe4a804d79e7788ab136290e609f91cf68423f"><code>ddfe4a8</code></a>
[perf] Reduce the amount of <code>crypto.randomFillSync()</code>
calls</li>
<li><a
href="https://github.com/websockets/ws/commit/b73b11828d166e9692a9bffe9c01a7e93bab04a8"><code>b73b118</code></a>
[dist] 8.17.0</li>
<li><a
href="https://github.com/websockets/ws/commit/29694a5905fa703e86667928e6bacac397469471"><code>29694a5</code></a>
[test] Use the <code>highWaterMark</code> variable</li>
<li><a
href="https://github.com/websockets/ws/commit/934c9d6b938b93c045cb13e5f7c19c27a8dd925a"><code>934c9d6</code></a>
[ci] Test on node 22</li>
<li><a
href="https://github.com/websockets/ws/commit/1817bac06e1204bfb578b8b3f4bafd0fa09623d0"><code>1817bac</code></a>
[ci] Do not test on node 21</li>
<li><a
href="https://github.com/websockets/ws/commit/96c9b3deddf56cacb2d756aaa918071e03cdbc42"><code>96c9b3d</code></a>
[major] Flip the default value of <code>allowSynchronousEvents</code>
(<a
href="https://redirect.github.com/websockets/ws/issues/2221">#2221</a>)</li>
<li><a
href="https://github.com/websockets/ws/commit/e5f32c7e1e6d3d19cd4a1fdec84890e154db30c1"><code>e5f32c7</code></a>
[fix] Emit at most one event per event loop iteration (<a
href="https://redirect.github.com/websockets/ws/issues/2218">#2218</a>)</li>
<li>Additional commits viewable in <a
href="https://github.com/websockets/ws/compare/8.16.0...8.17.1">compare
view</a></li>
</ul>
</details>
<br />


[![Dependabot compatibility
score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=ws&package-manager=npm_and_yarn&previous-version=8.16.0&new-version=8.17.1)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)

Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.

[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)

---

<details>
<summary>Dependabot commands and options</summary>
<br />

You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
You can disable automated security fix PRs for this repo from the
[Security Alerts
page](https://github.com/paritytech/polkadot-sdk/network/alerts).

</details>

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Branislav Kontur <bkontur@gmail.com>

PR changes forklift authentication to gcs

cc paritytech/ci_cd#987

This PR:

- Adds extra functionality to pallet-nfts's `BenchmarkHelper` to provide
signers and sign message.
- Abstracts away the explicit link with Sr25519 schema in the
benchmarks, allowing parachains with a different one to be able to run
them and calculate the weights.
- Adds a default implementation for the empty tuple that leaves the code
equivalent.

Changes:
- The XCMP queue does not partially modify pages anymore by using
`try_mutate` instead of `mutate`.
- The XCMP queue max page size is now the min between the value that the
relay reports and the local limit.

Thanks to whom pointed this out to me via DM.

---------

Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>

Closes #3342

cc/ @liamaharon

TODO:

- [x] Improve docs.
- [x] Define public interface (See #3342).
  In case we define public calls to the pallet implementation:
  - Implement public calls.
  - Benchmarks.
  
polkadot address: 12gMhxHw8QjEwLQvnqsmMVY1z5gFa54vND74aMUbhhwN6mJR

---------

Co-authored-by: command-bot <>
Co-authored-by: Liam Aharon <liam.aharon@hotmail.com>

Add `From` implementation used by downstream project.

Ref.
#4198 (comment)

CC @nazar-pc

Closes: #4748

…ero cost (#4596)

`Consideration` trait generic over `Footprint` and indicates zero cost
for a give footprint.

`Consideration` trait is generic over `Footprint` (currently defined
over the type with the same name). This makes it possible to setup a
custom footprint (e.g. current number of proposals in the storage).

`Consideration::new` and `Consideration::update` return an
`Option<Self>` instead `Self`, this make it possible to indicate a no
cost for a specific footprint (e.g. if current number of proposals in
the storage < max_proposal_count / 2 then no cost).

These cases need to be handled for
#3151

As per #3326, removes pallet::getter macro usage from the
pallet-elections-phragmen. The syntax `StorageItem::<T, I>::get()`
should be used instead.

cc @muraca

---------

Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>

…eration (#4833)

Currently the `Initialize` and `Reinitialize` messages in the
collationGeneration subsystem fail if:
-  `Initialize` if there exists already another configuration and
- `Reinitialize` if another configuration does not exist

I propose to instead change the behaviour of `Reinitialize` to always
set the config regardless of whether one exists or not.

---------

Co-authored-by: Bastian Köcher <git@kchr.de>
Co-authored-by: Andrei Sandu <54316454+sandreim@users.noreply.github.com>

I carried these things in a fork for a long time, I think wouldn't hurt
to have it upstream.

Originally submitted as part of
#1598 that went nowhere.

---------

Co-authored-by: Bastian Köcher <git@kchr.de>

Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>

### ISSUE
Link to the issue:
#1143

Deliverables
 - Implement trait `ContainsLengthBound` for pallet-membership
 

### Test Outcomes
___
Successful tests by running `cargo test -p pallet-membership --features
runtime-benchmarks`



running 22 tests
test tests::__construct_runtime_integrity_test::runtime_integrity_tests
... ok
test benchmark::bench_clear_prime ... ok
test tests::add_member_works ... ok
test tests::change_key_with_same_caller_as_argument_changes_nothing ...
ok
test tests::change_key_works ... ok
test benchmark::bench_set_prime ... ok
test benchmark::bench_remove_member ... ok
test benchmark::bench_change_key ... ok
test tests::change_key_works_that_does_not_change_order ... ok
test benchmark::bench_reset_members ... ok
test benchmark::bench_add_member ... ok
test tests::genesis_build_panics_with_duplicate_members - should panic
... ok
test benchmark::bench_swap_member ... ok
test tests::query_membership_works ... ok
test tests::prime_member_works ... ok
test tests::test_genesis_config_builds ... ok
test tests::remove_member_works ... ok
test tests::migration_v4 ... ok
test tests::swap_member_with_identical_arguments_changes_nothing ... ok
test tests::swap_member_works_that_does_not_change_order ... ok
test tests::swap_member_works ... ok
test tests::reset_members_works ... ok

test result: ok. 22 passed; 0 failed; 0 ignored; 0 measured; 0 filtered
out; finished in 0.01s

   Doc-tests pallet_membership

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered
out; finished in 0.00s

---------

Co-authored-by: Bastian Köcher <git@kchr.de>

When `min_enactment_period == 0` and `desired == At(n)` where `n` is
smaller than the current block number, the scheduling would fail. This
happened for example here:
https://collectives.subsquare.io/fellowship/referenda/126

To ensure that this doesn't happen again, ensure that the earliest
allowed block is at minimum the next block.

After preparing in #4633,
we can lift also all internal dependencies up to the workspace.

This does not actually change anything, but uses `workspace = true` for
all dependencies. You can check it with:
```bash
git checkout -q $(git merge-base oty-lift-all-deps origin/master)
cargo tree -e features > master.out

git checkout -q oty-lift-all-deps
cargo tree -e features > new.out
diff master.out new.out
```

It did not yet lift 100% of dependencies, some inside of `target.*` or
some that had conflicting aliases introduced recently. But i will do
these together in a follow-up with CI checks.

Can be reproduced with [zepter](https://github.com/ggwpez/zepter/):
`zepter transpose d lift-to-workspace "regex:.*" --version-resolver
highest --skip-package "polkadot-sdk" --ignore-errors --fix`.

---------

Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>

Configuration for the maximum member count per rank, with the option for
no limit.

Pull the Rust dependencies in advance to see if there is an issue with
timeouts.

---------

Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>

Remove unused config parameters `ApproveOrigin` and `OnSlash` from the
treasury pallet. Add `OnSlash` config parameter to the bounties and tips
pallets.

part of #3800

Signed-off-by: dashangcun <jchaodaohang@foxmail.com>
Co-authored-by: dashangcun <jchaodaohang@foxmail.com>

…4872)

We should not print a warning if the best block stays the same between
two finality events. There is no requirement that this changes. For sure
this doesn't need to be an error message.

…ypes in sp-core (#4860)

Some primitives have impl Hex related traits enabled by `rustc-hex`
feature. People wanna use H256/H160 maybe need these trait impls

---------

Co-authored-by: command-bot <>
Co-authored-by: Bastian Köcher <git@kchr.de>

While working on #4600 I
found that it would be nice if `chain-spec-builder` supported
`codeSubstitutes`. After this PR is merged you can do:

```
chain-spec-builder add-code-substitute chain_spec.json my_runtime.compact.compressed.wasm 1234
```

In addition, the `chain-spec-builder` was silently removing
`relay_chain` and `para_id` fields when used on parachain chain-specs.
This is now fixed by providing a custom chain-spec extension that has
these fields marked as optional.

Upgrade libp2p to 0.52.4, including a fix: 

* Set Kademlia to server mode
(paritytech/substrate#14703)

### TODO
- [x] Fix 3 zombienet tests failing:
  - [x] `zombienet-substrate-0002-validators-warp-sync`
- [ ]
~`zombienet-polkadot-functional-0005-parachains-disputes-past-session`~
The test is also flaky in other PRs and is not required for CI to
succeed.
  - [x] `zombienet-polkadot-functional-0009-approval-voting-coalescing`
- [x] Uncomment and update to the actual libp2p API tests in
[`substrate/client/network/src/protocol/notifications/handler.rs`](https://github.com/paritytech/polkadot-sdk/blob/7331f1796f1a0b0e9fb0cd7bf441239ad9664595/substrate/client/network/src/protocol/notifications/handler.rs#L1009).
- [x] When upgrading `multihash` crate as part of libp2p upgrade to
version v0.19.1, uncomment the conversion code at
https://github.com/paritytech/polkadot-sdk/blob/7547c4942a887029c11cbcfd5103f6d8315ab95c/substrate/client/network/types/src/multihash.rs#L159
- [x] Perform a burn-in.

---------

Co-authored-by: Anton <anton.kalyaev@gmail.com>
Co-authored-by: command-bot <>
Co-authored-by: Dmitry Markin <dmitry@markin.tech>
Co-authored-by: Bastian Köcher <git@kchr.de>

Fixes #4723. Also,
closes #4622

As stated in the linked issue, this PR adds the ability to use a real
rust type for pallet alias in the new `runtime` macro:
```rust
#[runtime::pallet_index(0)]
pub type System = frame_system::Pallet<Runtime>;
```

Please note that the current syntax still continues to be supported.

CC: @shawntabrizi @kianenigma

---------

Co-authored-by: command-bot <>
Co-authored-by: Bastian Köcher <git@kchr.de>

A few refactorings to block import and block verification that should
not be controversial.

Block verification before block import is stateless by design as
described in https://substrate.stackexchange.com/a/1322/25 and the fact
that it wasn't yet I consider to be a bug. Some code that requires it
had to use `Mutex`, but I do not expect it to have a measurable
performance impact.

Similarly with block import checking whether block preconditions should
not be an exclusive operation, there is nothing fundamentally wrong with
checking a few competing blocks whose parent blocks exist at the same
time (and even import them concurrently later, though IIRC this is not
yet implemented either).

They were originally a part of
#4842 and upstreaming
will help us to reduce the size of the patch we need to apply on top of
upstream code at Subspace every time we upgrade. There are no new
features introduced here, just refactoring to get rid of unnecessary
requirements.

Introduce migration type to remove data associated with a specific
storage of a pallet.

Based on existing `RemovePallet` migration type.

Required for #3820

---------

Co-authored-by: Liam Aharon <liam.aharon@hotmail.com>
Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com>

This is PR updates jsonrpsee v0.23 which mainly changes:
- Add `Extensions` which we now is using to get the connection id (used
by the rpc spec v2 impl)
- Update hyper to v1.0, http v1.0, soketto and related crates
(hyper::service::make_service_fn is removed)
- The subscription API for the client is modified to know why a
subscription was closed.

Full changelog here:
https://github.com/paritytech/jsonrpsee/releases/tag/v0.23.0

---------

Co-authored-by: Bastian Köcher <git@kchr.de>

Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>

Closes: #4298

This PR also merges `xcm-fee-payment-runtime-api` module to the
`xcm-runtime-api`.


## TODO

- [x] rename `convert` to `convert_location` and add new one
`convert_account` (opposite direction)
- [x] add to the all testnet runtimes
- [x] check polkadot-js if supports that automatically or if needs to be
added manually polkadot-js/api#5917
- [ ] backport/patch for fellows and release (asap)

## Open questions
- [x] should we merge `xcm-runtime-api` and
`xcm-fee-payment-runtime-api` to the one module `xcm-runtime-api` ?

## Usage
Input:
 - `location:  VersionedLocation`
 
Output:
 - account_id bytes


![image](https://github.com/paritytech/polkadot-sdk/assets/8159517/4607b15a-77d2-462b-806c-606107776c0d)

---------

Co-authored-by: Bastian Köcher <git@kchr.de>

Add a `promote_fast` extrinsic to the `core-fellowship` pallet to allow
promotions that ignore the promotion cooldown. It comes with a new
`FastPromoteOrigin`.

Supersedes #4778

---------

Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
Co-authored-by: joe petrowski <25483142+joepetrowski@users.noreply.github.com>
Co-authored-by: command-bot <>

This PR upgrades `litep2p` to the latest version and includes the two
fixes:

1. Enables incoming DHT record validation with `litep2p` network
backend.
2. Sets `TCP_NODELAY` flag on TCP & WS sockets in `litep2p` backend, as
it is currently done in `libp2p` backend.

---------

Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>

Enables the `request_revenue` and `notify_revenue` parts of [RFC 5 -
Coretime
Interface](https://polkadot-fellows.github.io/RFCs/approved/0005-coretime-interface.html)

TODO:
- [x] Finish first pass at implementation
- [x] ~~Need to explicitly burn uncollected and dropped revenue~~
Accumulate it instead
- [x] Confirm working on zombienet
- [x] Tests 
- [ ] Enable XCM `request_revenue` sending on Coretime chain on Kusama
and Polkadot

Fixes: #2209

---------

Co-authored-by: Dmitry Sinyavin <dmitry.sinyavin@parity.io>
Co-authored-by: command-bot <>
Co-authored-by: s0me0ne-unkn0wn <48632512+s0me0ne-unkn0wn@users.noreply.github.com>
Co-authored-by: Dónal Murray <donal.murray@parity.io>
Co-authored-by: Bastian Köcher <git@kchr.de>

Introduce an optional auto-increment setup for the IDs of new assets.

---------

Co-authored-by: joe petrowski <25483142+joepetrowski@users.noreply.github.com>
Co-authored-by: Bastian Köcher <git@kchr.de>

Co-authored-by: gupnik <mail.guptanikhil@gmail.com>

Ensure that the key ownership proof doesn't contain duplicate or
unneeded nodes.

We already have these checks for the bridge messages proof. Just making
them more generic and performing them also for the key ownership proof.

---------

Co-authored-by: Adrian Catangiu <adrian@parity.io>

Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>

Co-authored-by: command-bot <>

Partly fixes
#4890 (comment)

Still the offchain API needs to be updated to hyper v1.0 and I opened an
issue for it, it's using low-level http body features that have been
removed

Adding `Runtime::OmniNode` variant + small changes

---------

Co-authored-by: kianenigma <kian@parity.io>

Update the instructions to work with the latest parachain template on
Polkadot SDK

---------

Co-authored-by: kianenigma <kian@parity.io>
Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com>

…o Asset Hubs (#4888)

On Westend Asset Hub, we allow Rococo Asset Hub to act as reserve for
any asset native to the Rococo or Ethereum ecosystems (practically
providing Westend access to Ethereum assets through double bridging:
W<>R<>Eth).

On Rococo Asset Hub, we allow Westend Asset Hub to act as reserve for
any asset native to the Westend ecosystem. We also allow Ethereum
contracts to act as reserves for the foreign assets identified by the
same respective contracts locations.

- [x] add emulated tests for various assets (native, trust-based,
foreign/bridged) going AHR -> AHW,
- [x] add equivalent tests for the other direction AHW -> AHR.

This PR is a prerequisite to doing the same for Polkadot<>Kusama bridge.

… Westend) (#4738)

This adds the new `SignedExtension` to Coretime Rococo and Coretime
Westend runtimes.

---------

Co-authored-by: Dónal Murray <donal.murray@parity.io>

Counterpart of: #4031

cc @paritytech/networking

---------

Signed-off-by: Alexandru Vasile <alexandru.vasile@parity.io>
Co-authored-by: Sebastian Kunert <skunert49@gmail.com>

As per #3326 , removes pallet::getter macro usage from
pallet-membership. The syntax StorageItem::<T, I>::get() should be used
instead. Also converts some syntax to turbo and reimplements the removed
getters, following #223

cc @muraca

---------

Co-authored-by: Dónal Murray <donalm@seadanda.dev>
Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com>

Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>

Added Instructions for pallet name customisation in the ReadMe

---------

Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
Co-authored-by: Bastian Köcher <git@kchr.de>

Co-authored-by: Bastian Köcher <git@kchr.de>

CI required markdown step seems to start failing after
#4806

Signed-off-by: Alexandru Gheorghe <alexandru.gheorghe@parity.io>

… AURA (#4932)

Recently thought about the special handling we have for asset-hub
chains. They started with relay chain consensus and transitioned to AURA
at some point. However, nobody should be authoring with relay chain
consensus on these chains anymore, the transition is long done.

I propose to remove this special handling, allowing us to unify one more
execution path.

This PR exposes the `RandomKademliaStarted` event from the litep2p
network backend, and then increments the appropriate metrics.

This is part of: #4681.
However, it is more of an effort to debug low peer count 

### Testing Done
- Started a node and fetched queries:
`substrate_sub_libp2p_kademlia_random_queries_total` produces results
for litep2p backend

cc @paritytech/networking

---------

Signed-off-by: Alexandru Vasile <alexandru.vasile@parity.io>

…set hub (#4870)

- Send bridged WNDs: Penpal Rococo -> AH Rococo -> AH Westend
- Send bridged ROCs: Penpal Westend -> AH Westend -> AH Rococo

The tests send both ROCs and WNDs, for each direction the native asset
is only used to pay for the transport fees on the local AssetHub, and
are not sent over the bridge.

Including the native asset won't be necessary anymore once we get #4375.

---------

Signed-off-by: Adrian Catangiu <adrian@parity.io>
Co-authored-by: command-bot <>

With random connectivity and latency is hard to actually figure it out a
delta in the benchmarking, so disable them in order to get full
deterministic behaviour when measuring performance.

At least on my machine with this configuration the results for
approval-throughput are really similar between subsequent runs:

```
CPU usage, seconds                     total   per block

approval-distribution                36.9025      3.6902
approval-distribution                36.7579      3.6758
approval-distribution                37.0418      3.7042
approval-distribution                37.0339      3.7034
approval-distribution                36.9342      3.6934
approval-distribution                36.7177       3.6718



approval-voting                      52.7756      5.2776
approval-voting                      52.5999      5.2600
approval-voting                      53.2158      5.3216
approval-voting                      53.2493      5.3249
approval-voting                      52.8524      5.2852
approval-voting                      52.8611      5.2861
approval-voting                      52.8210      5.2821
```

---------

Signed-off-by: Alexandru Gheorghe <alexandru.gheorghe@parity.io>

This PR fixes the unused warnings in `frame-support-procedural` crate,
raised by the latest stable rust release.

Related to #4523

Extracting part of #1903
(credits to @Lederstrumpf for the high-level strategy), but also
introducing significant adjustments both to the approach and to the
code. The main adjustment is the fact that the `ForkVotingProof` accepts
only one vote, compared to the original version which accepted a
`vec![]`. With this approach more calls are needed in order to report
multiple equivocated votes on the same commit, but it simplifies a lot
the checking logic. We can add support for reporting multiple signatures
at once in the future.

There are 2 things that are missing in order to consider this issue
done, but I would propose to do them in a separate PR since this one is
already pretty big:
- benchmarks/computing a weight for the new extrinsic (this wasn't
present in #1903 either)
- exposing an API for generating the ancestry proof. I'm not sure if we
should do this in the Mmr pallet or in the Beefy pallet

Co-authored-by: Robert Hambrock <roberthambrock@gmail.com>

---------

Co-authored-by: Adrian Catangiu <adrian@parity.io>

Related: #4804.
Fixes the try state error in Westend:
https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/6564522.
Passes here:
https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/6580393

## Context
Currently in Kusama and Polkadot, an account can do both, directly
stake, and join a pool.

With the migration of pools to `DelegateStake` (See
#3905), the funds of pool
members are locked in a different way than for direct stakers.
- Pool member funds uses `holds`.
- `pallet-staking` uses deprecated locks (analogous to freeze) which can
overlap with holds.

An existing delegator can stake directly since pallet-staking only uses
free balance. But once an account becomes staker, we cannot allow them
to be delegator as this risks an account to use already staked (frozen)
funds in pools.

When an account gets into a situation where it is participating in both
pools and staking, it would no longer would be able to add any extra
bond to the pool but they can still withdraw funds.

## Changes
- Add test for the above scenario.
- Removes the assumption that a delegator cannot be a staker.

### ISSUE
Link to the issue:
#3326
cc @muraca 

Deliverables
 - [Deprecation] remove pallet::getter usage from all pallet-tips
 

### Test Outcomes
___
Successful tests by running `cargo test -p pallet-tips --features
runtime-benchmarks`



running 26 tests
test tests::__construct_runtime_integrity_test::runtime_integrity_tests
... ok
test benchmarking::bench_retract_tip ... ok
test tests::equal_entries_invariant ... ok
test benchmarking::bench_tip ... ok
test tests::finders_fee_invariant ... ok
test tests::genesis_config_works ... ok
test tests::genesis_funding_works ... ok
test benchmarking::bench_slash_tip ... ok
test tests::reasons_invariant ... ok
test benchmarking::bench_report_awesome ... ok
test tests::close_tip_works ... ok
test tests::report_awesome_from_beneficiary_and_tip_works ... ok
test tests::test_genesis_config_builds ... ok
test tests::test_last_reward_migration ... ok
test benchmarking::bench_tip_new ... ok
test benchmarking::bench_close_tip ... ok
test tests::test_migration_v4 ... ok
test tests::slash_tip_works ... ok
test tests::report_awesome_and_tip_works_second_instance ... ok
test tests::report_awesome_and_tip_works ... ok
test tests::tip_changing_works ... ok
test tests::zero_base_deposit_prohibited - should panic ... ok
test tests::tip_median_calculation_works ... ok
test tests::tip_new_cannot_be_used_twice ... ok
test tests::tip_large_should_fail ... ok
test tests::retract_tip_works ... ok

test result: ok. 26 passed; 0 failed; 0 ignored; 0 measured; 0 filtered
out; finished in 0.02s

   Doc-tests pallet_tips

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered
out; finished in 0.00s

---

Polkadot Address: 16htXkeVhfroBhL6nuqiwknfXKcT6WadJPZqEi2jRf9z4XPY

---------

Co-authored-by: Bastian Köcher <git@kchr.de>

…etBackableCandidates` (#4921)

**Backable Candidate**: If a candidate receives enough supporting
Statements from the Parachain Validators currently assigned, that
candidate is considered backable.
**Backed Candidate**: A Backable Candidate noted in a relay-chain block

---

When the candidate backing subsystem receives the `GetBackedCandidates`
message, it sends back **backable** candidates, not **backed**
candidates. So we should rename this message to `GetBackableCandidates`

Co-authored-by: Bastian Köcher <git@kchr.de>

…4839)

As per #3326, removes pallet::getter macro usage from the
pallet-insecure-randomness-collective-flip. The syntax `StorageItem::<T,
I>::get()` should be used instead.

Explicitly implements the getters that were removed as well, following
#223

Also makes the storage values public and converts some syntax to turbo

cc @muraca

---------

Co-authored-by: Bastian Köcher <git@kchr.de>
Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>

Part of #3168 
On top of #3568

### Changes Overview
- Introduces a new collator variant in
`cumulus/client/consensus/aura/src/collators/slot_based/mod.rs`
- Two tasks are part of that module, one for block building and one for
collation building and submission.
- Introduces a new variant of `cumulus-test-runtime` which has 2s slot
duration, used for zombienet testing
- Zombienet tests for the new collator

**Note:** This collator is considered experimental and should only be
used for testing and exploration for now.

### Comparison with `lookahead` collator
- The new variant is slot based, meaning it waits for the next slot of
the parachain, then starts authoring
- The search for potential parents remains mostly unchanged from
lookahead
- As anchor, we use the current best relay parent
- In general, the new collator tends to be anchored to one relay parent
earlier. `lookahead` generally waits for a new relay block to arrive
before it attempts to build a block. This means the actual timing of
parachain blocks depends on when the relay block has been authored and
imported. With the slot-triggered approach we are authoring directly on
the slot boundary, were a new relay chain block has probably not yet
arrived.

### Limitations
- Overall, the current implementation focuses on the "happy path"
- We assume that we want to collate close to the tip of the relay chain.
It would be useful however to have some kind of configurable drift, so
that we could lag behind a bit.
#3965
- The collation task is pretty dumb currently. It checks if we have
cores scheduled and if yes, submits all the messages we have received
from the block builder until we have something submitted for every core.
Ideally we should do some extra checks, i.e. we do not need to submit if
the built block is already too old (build on a out of range relay
parent) or was authored with a relay parent that is not an ancestor of
the relay block we are submitting at.
#3966
- There is no throttling, we assume that we can submit _velocity_ blocks
every relay chain block. There should be communication between the
collator task and block-builder task.
- The parent search and ConsensusHook are not yet properly adjusted. The
parent search makes assumptions about the pending candidate which no
longer hold. #3967
- Custom triggers for block building not implemented.

---------

Co-authored-by: Davide Galassi <davxy@datawok.net>
Co-authored-by: Andrei Sandu <54316454+sandreim@users.noreply.github.com>
Co-authored-by: Bastian Köcher <git@kchr.de>
Co-authored-by: Javier Viola <363911+pepoviola@users.noreply.github.com>
Co-authored-by: command-bot <>

Related to recent discussion. PR makes timeout less strict.

cc paritytech/ci_cd#996

Timing issues in container startup have made this test flaky. We now
wait for 20 and then register the parachain.
This makes sure that the parachain node has the ability to see all relay
chain notifications it needs.

### ISSUE
Link to the issue:
#3326

cc @muraca 

Deliverables
 - [Deprecation] remove pallet::getter usage from all pallet-vesting
 

### Test Outcomes
___
Successful tests by running `cargo test -p pallet-vesting --features
runtime-benchmarks`

running 45 tests
test benchmarking::bench_force_vested_transfer ... ok
test benchmarking::bench_vest_other_locked ... ok
test mock::__construct_runtime_integrity_test::runtime_integrity_tests
... ok
test benchmarking::bench_not_unlocking_merge_schedules ... ok
test benchmarking::bench_unlocking_merge_schedules ... ok
test mock::test_genesis_config_builds ... ok
test tests::build_genesis_has_storage_version_v1 ... ok
test tests::check_vesting_status ... ok
test benchmarking::bench_force_remove_vesting_schedule ... ok
test tests::check_vesting_status_for_multi_schedule_account ... ok
test benchmarking::bench_vest_locked ... ok
test tests::extra_balance_should_transfer ... ok
test tests::generates_multiple_schedules_from_genesis_config ... ok
test tests::force_vested_transfer_allows_max_schedules ... ok
test tests::force_vested_transfer_correctly_fails ... ok
test tests::force_vested_transfer_works ... ok
test tests::liquid_funds_should_transfer_with_delayed_vesting ... ok
test tests::merge_finished_and_ongoing_schedules ... ok
test benchmarking::bench_vest_unlocked ... ok
test tests::merge_finished_and_yet_to_be_started_schedules ... ok
test tests::merge_finishing_schedules_does_not_create_a_new_one ... ok
test tests::merge_ongoing_and_yet_to_be_started_schedules ... ok
test benchmarking::bench_vest_other_unlocked ... ok
test tests::merge_ongoing_schedules ... ok
test tests::merge_schedules_that_have_not_started ... ok
test tests::merge_vesting_handles_per_block_0 ... ok
test tests::per_block_works ... ok
test tests::merge_schedules_throws_proper_errors ... ok
test tests::multiple_schedules_from_genesis_config_errors - should panic
... ok
test tests::merging_shifts_other_schedules_index ... ok
test tests::non_vested_cannot_vest_other ... ok
test tests::unvested_balance_should_not_transfer ... ok
test tests::non_vested_cannot_vest ... ok
test tests::vested_balance_should_transfer ... ok
test tests::remove_vesting_schedule ... ok
test tests::vested_transfer_correctly_fails ... ok
test tests::vested_balance_should_transfer_with_multi_sched ... ok
test tests::vested_balance_should_transfer_using_vest_other ... ok
test tests::vested_transfer_less_than_existential_deposit_fails ... ok
test tests::vesting_info_ending_block_as_balance_works ... ok
test tests::vesting_info_validate_works ... ok
test
tests::vested_balance_should_transfer_using_vest_other_with_multi_sched
... ok
test tests::vested_transfer_works ... ok
test tests::vested_transfer_allows_max_schedules ... ok
test benchmarking::bench_vested_transfer ... ok

test result: ok. 45 passed; 0 failed; 0 ignored; 0 measured; 0 filtered
out; finished in 0.10s

---

Polkadot Address: 16htXkeVhfroBhL6nuqiwknfXKcT6WadJPZqEi2jRf9z4XPY

This PR largely fixes
#4903 by addressing it
from a few different directions.

The high-level observation is that complexity of finalization was
unfortunately roughly `O(n^3)`. Not only
`displaced_leaves_after_finalizing` was extremely inefficient on its
own, especially when large ranges of blocks were involved, it was called
once upfront and then on every single block that was finalized over and
over again.

The first commit refactores code adjacent to
`displaced_leaves_after_finalizing` to optimize memory allocations. For
example things like `BTreeMap<_, Vec<_>>` were very bad in terms of
number of allocations and after analyzing code paths was completely
unnecessary and replaced with `Vec<(_, _)>`. In other places allocations
of known size were not done upfront and some APIs required unnecessary
cloning of vectors.

I checked invariants and didn't find anything that was violated after
refactoring.

Second commit completely replaces `displaced_leaves_after_finalizing`
implementation with a much more efficient one. In my case with ~82k
blocks and ~13k leaves it takes ~5.4s to finish
`client.apply_finality()` now.

The idea is to avoid querying the same blocks over and over again as
well as introducing temporary local cache for blocks related to leaves
above block that is being finalized as well as local cache of the
finalized branch of the chain. I left some comments in the code and
wrote tests that I belive should check all code invariants for
correctness. `lowest_common_ancestor_multiblock` was removed as
unnecessary and not great in terms of performance API, domain-specific
code should be written instead like done in
`displaced_leaves_after_finalizing`.

After these changes I noticed finalization is still horribly slow,
turned out that even though `displaced_leaves_after_finalizing` was way
faster that before (probably order of magnitude), it was called for
every single of those 82k blocks 🤦

The quick hack I came up with in the third commit to handle this edge
case was to not call it when finalizing multiple blocks at once until
the very last moment. It works and allows to finish the whole
finalization in just 14 seconds (5.4+5.4 of which are two calls to
`displaced_leaves_after_finalizing`). I'm really not happy with the fact
that `displaced_leaves_after_finalizing` is called twice, but much
heavier refactoring would be necessary to get rid of second call.

---

Next steps:
* assuming the changes are acceptable I'll write prdoc
* #4920 or something
similar in spirit should be implemented to unleash efficient parallelsm
with rayon in `displaced_leaves_after_finalizing`, which will allow to
further (and significant!) scale its performance rather that being
CPU-bound on a single core, also reading database sequentially should
ideally be avoided
* someone should look into removal of the second
`displaced_leaves_after_finalizing` call
* further cleanups are possible if `undo_finalization` can be removed

---

Polkadot Address: 1vSxzbyz2cJREAuVWjhXUT1ds8vBzoxn2w4asNpusQKwjJd

---------

Co-authored-by: Sebastian Kunert <skunert49@gmail.com>