This PR removes the `check-migrations` pipelines for all Rococo chains
because they are going down:
https://github.com/paritytech/devops/issues/3589, and these checks are
starting to fail, e.g.:

https://github.com/paritytech/polkadot-sdk/actions/runs/11339904745/job/31535485254?pr=4982

https://github.com/paritytech/polkadot-sdk/actions/runs/11339904745/job/31535486189?pr=4982

https://github.com/paritytech/polkadot-sdk/actions/runs/11339904745/job/31535486471?pr=4982

Additionally, `coretime-westend` was added to the `check-migrations`
matrix.

fixes #5981 

Could confirm the issue with the added tests:

```
test tests/split_ui/pass/split_call.rs [should pass] ... error
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
error[E0423]: expected value, found attribute macro `origin`
  --> tests/split_ui/pass/split_call.rs:23:1
   |
23 | #[frame_support::pallet(dev_mode)]
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not a value
   |
   = note: this error originates in the attribute macro `frame_support::pallet` (in Nightly builds, run with -Z macro-backtrace for more info)
```

# Description

`origin` unexpectedly resolved to a macro, which is available at the
span of invocation. The solution here is to use the expansion as a
function instead of a call and pass in the desired values to avoid
ambiguities.

Testing the approach of this before it goes live on Polkadot
https://github.com/polkadot-fellows/runtimes/pull/471

---------

Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
Co-authored-by: Dónal Murray <donal.murray@parity.io>

fatp_limits_watcher_non_intial_view_drops_transaction was rarely failing

Use the umbrella crate for the parachain template

This covers almost all the dependencies. There are just a few exceptions
for which I created a separate issue:
https://github.com/paritytech/polkadot-sdk/issues/5993

Also related to: https://github.com/paritytech/polkadot-sdk/issues/4782

30 hrs -> 72 hours
as it has stopped by timeout here
https://github.com/paritytech/polkadot-sdk/actions/runs/11299872333/job/31431758932

fixes #5320 @sam0x17 @gupnik 

# Description

The issue could be confirmed with the added example. The cause is for
macro hygiene, `entries` in the `#( #entries_builder )*` expansion won't
be able to reference the `entries` defined outside. The solution here is
to allow the reference to be passed into the expansion with closure.

Or we could just switch to the unhygienic span with `quote::quote!`
instead such that `entries` will resolve to the "outer" definition.

### Improved devx of running many pallets simultaneously

Changes to /cmd:
- Replace (flip) `--continue-on-fail` with `--fail-fast`, but only for
`bench`. This makes all pallets/runtimes run non-stop by default, as it
was primary use-case during tests
- The list of successful/failed pallets was hard to find within tons of
logs, so decided to write only needed logs in a file, and output as a
summary in the workflow and in the comment
- Side fix: updated `tasks_example` to `pallet_example_tasks` to make
compliant with standard naming

<img width="1006" alt="image"
src="https://github.com/user-attachments/assets/14896041-7018-4a0d-92b7-4508e81913c2">

+ added command results to workflow summary:
<img width="1275" alt="image"
src="https://github.com/user-attachments/assets/b4a8afdb-dc9f-4ff9-9720-28a88956035f">

---------

Co-authored-by: GitHub Action <action@github.com>

Some of the features enabled for `polkadot-sdk` umbrella crate were not
necessary for substrate node (e.g. all `cumulus-*` or `polkadot-*`
features) resulting in much longer compilation time. This PR fixes that.

# Description

When we send `QueueEvent::StartWork`, we have already completed the
execution. This may be a leftover of a previous logic change. Currently,
the name is misleading, so it would be better to rename it to
`FinishWork`.


https://github.com/paritytech/polkadot-sdk/blob/c52675ef/polkadot/node/core/pvf/src/execute/queue.rs#L632-L646


https://github.com/paritytech/polkadot-sdk/blob/c52675ef

/polkadot/node/core/pvf/src/execute/queue.rs#L361-L363

Fixes https://github.com/paritytech/polkadot-sdk/issues/5910

## Integration

Shouldn't affect downstream projects.

---------

Co-authored-by: GitHub Action <action@github.com>

The `quick-benchmarks-omni` job was moved to GHA (can be found
[here](https://github.com/paritytech/polkadot-sdk/blob/439b31ef/.github/workflows/check-frame-omni-bencher.yml#L22))
but hasn't been removed from GitLab . PR fixes it and makes the check
required.

1800 min

Resolves https://github.com/paritytech/polkadot-sdk/issues/5972

Only needed to increase some timeouts

# Description

This PR addresses
https://github.com/paritytech/polkadot-sdk/issues/5878.

After dry running an xcm on asset hub, we had redundant xcms showing up
in the `forwarded_xcms` field of the dry run effects returned.
These were caused by two things:
- The `UpwardMessageSender` router always added an element even if there
were no messages.
- The two routers on asset hub westend related to bridging (to rococo
and sepolia) getting the message from their queues when their queues is
actually the same xcmp queue that was already contemplated.

In order to fix this, we check for no messages in UMP and clear the
implementation of `InspectMessageQueues` for these bridging routers.
Keep in mind that the bridged message is still sent, as normal via the
xcmp-queue to Bridge Hub.
To keep on dry-running the journey of the message, the next hop to
dry-run is Bridge Hub.
That'll be tackled in a different PR.

Added a test in `bridge-hub-westend-integration-tests` and
`bridge-hub-rococo-integration-tests` that show that dry-running a
transfer across the bridge from asset hub results in one and only one
message sent to bridge hub.

## TODO
- [x] Functionality
- [x] Test

---------

Co-authored-by: command-bot <>

✄
-----------------------------------------------------------------------------

Thank you for your Pull Request! 

 Please make sure it follows the
contribution guidelines outlined in [this

document](https://github.com/paritytech/polkadot-sdk/blob/master/docs/contributor/CONTRIBUTING.md)
and fill out the
sections below. Once you're ready to submit your PR for review, please
delete this section and leave only the text under
the "Description" heading.

# Description

Please consider adding RadiumBlock bootnodes to Coretime Polkadot Chain
spec

## Integration

*In depth notes about how this PR should be integrated by downstream
projects. This part is mandatory, and should be
reviewed by reviewers, if the PR does NOT have the `R0-Silent` label. In
case of a `R0-Silent`, it can be ignored.*

## Review Notes

*In depth notes about the **implementation** details of your PR. This
should be the main guide for reviewers to
understand your approach and effectively review it. If too long, use

[`<details>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/details)*.

*Imagine that someone who is depending on the old code wants to
integrate your new code and the only information that
they get is this section. It helps to include example usage and default
value here, with a `diff` code-block to show
possibly integration.*

*Include your leftover TODOs, if any, here.*

# Checklist

* [x] My PR includes a detailed description as outlined in the
"Description" and its two subsections above.
* [ ] My PR follows the [labeling requirements](

https://github.com/paritytech/polkadot-sdk/blob/master/docs/contributor/CONTRIBUTING.md#Process
) of this project (at minimum one label for `T` required)
* External contributors: ask maintainers to put the right label on your
PR.
* [ ] I have made corresponding changes to the documentation (if
applicable)
* [ ] I have added tests that prove my fix is effective or that my
feature works (if applicable)

You can remove the "Checklist" section once all have been checked. Thank
you for your contribution!

✄
-----------------------------------------------------------------------------

Co-authored-by: Veena <veena.john@radiumblock.com>
Co-authored-by: Dónal Murray <donal.murray@parity.io>

Bumps [strum](https://github.com/Peternator7/strum) from 0.26.2 to
0.26.3.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/Peternator7/strum/releases">strum's
releases</a>.</em></p>
<blockquote>
<h2>v0.26.3</h2>
<h2>What's Changed</h2>
<ul>
<li>Fix typos &amp; misspellings in docs by <a
href="https://github.com/5-pebbles"><code>@​5-pebbles</code></a> in <a
href="https://redirect.github.com/Peternator7/strum/pull/347">Peternator7/strum#347</a></li>
<li>Update <code>heck</code> requirement by <a
href="https://github.com/smoelius"><code>@​smoelius</code></a> in <a
href="https://redirect.github.com/Peternator7/strum/pull/346">Peternator7/strum#346</a></li>
<li>Fix broken links by <a
href="https://github.com/rainbowatcher"><code>@​rainbowatcher</code></a>
in <a
href="https://redirect.github.com/Peternator7/strum/pull/350">Peternator7/strum#350</a></li>
<li>Interpolate unnamed enum variant fields in to_string attribute by ...

Resolves https://github.com/paritytech/polkadot-sdk/issues/4632

The new logic optimizes the distribution of execution jobs for disputes,
approvals, and backings. Testing shows improved finality lag and
candidate checking times, especially under heavy network load.

### Approach

This update adds prioritization to the PVF execution queue. The logic
partially implements the suggestions from
https://github.com/paritytech/polkadot-sdk/issues/4632#issuecomment-2209188695.

We use thresholds to determine how much a current priority can "steal"
from lower ones:
-  Disputes: 70%
-  Approvals: 80%
-  Backing System Parachains: 100%
-  Backing: 100%

A threshold indicates the portion of the current priority that can be
allocated from lower priorities.

For example:
-  Disputes take 70%, leaving 30% for approvals and all backings.
- 80% of the remaining goes to approvals, which is 30% * 80% = 24% of
the original 100%.
- If we used parts of the original 100%, approvals couldn't take more
than 24%, even if there are no disputes.

Assuming a maximum of 12 executions per block, with a 6-second window, 2
CPU cores, and a 2-second run time, we get these distributions:

-  With disputes: 8 disputes, 3 approvals, 1 backing
-  Without disputes: 9 approvals, 3 backings

It's worth noting that when there are no disputes, if there's only one
backing job, we continue processing approvals regardless of their
fulfillment status.

### Versi Testing 40/20

Testing showed a slight difference in finality lag and candidate
checking time between this pull request and its base on the master
branch. The more loaded the network, the greater the observed
difference.

Testing Parameters:
-  40 validators (4 malicious)
-  20 gluttons with 2 seconds of PVF execution time
-  6 VRF modulo samples
-  12 required approvals

![Pasted Graphic
3](https://github.com/user-attachments/assets/8b6163a4-a1c9-44c2-bdba-ce1ef4b1eba7)
![Pasted Graphic
4](https://github.com/user-attachments/assets/9f016647-7727-42e8-afe9-04f303e6c862)

### Versi Testing 80/40

For this test, we compared the master branch with the branch from
https://github.com/paritytech/polkadot-sdk/pull/5616. The second branch
is based on the current one but removes backing jobs that have exceeded
their time limits. We excluded malicious nodes to reduce noise from
disputing and banning validators. The results show that, under the same
load, nodes experience less finality lag and reduced recovery and check
time. Even parachains are functioning with a shorter block time,
although it remains over 6 seconds.

Testing Parameters:
-  80 validators (0 malicious)
-  40 gluttons with 2 seconds of PVF execution time
-  6 VRF modulo samples
-  30 required approvals


![image](https://github.com/user-attachments/assets/42bcc845-9115-4ae3-9910-286b77a60bbf)

---------

Co-authored-by: Andrei Sandu <54316454+sandreim@users.noreply.github.com>

Here are MD docs for V2 @acatangiu @franciscoaguirre

 . Let me know what
you think.

---------

Co-authored-by: Adrian Catangiu <adrian@parity.io>
Co-authored-by: Francisco Aguirre <franciscoaguirreperez@gmail.com>
Co-authored-by: Alistair Singh <alistair.singh7@gmail.com>

https://github.com/paritytech/polkadot-sdk/pull/5886#discussion_r1793423401

---------

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

PR moves `test-linux-stable-no-try-runtime` from gitlab to github.
I disabled two tests because our current runners don't have necessary
syscalls enabled. Will continue working on it in
https://github.com/paritytech/ci_cd/issues/1056
Also PR remove `gh cli` installation since it's installed in the
`ci-unified` image.

close https://github.com/paritytech/ci_cd/issues/1023

# Description

We previously set the PoV request timeout to 1.2s based on synchronous
backing, which allowed for 5 PoVs per relay block. With asynchronous
backing, we no longer have a time budget and can increase the value to
2s.

Fixes https://github.com/paritytech/polkadot-sdk/issues/5885

## Integration

This PR shouldn't affect downstream projects.

## Review Notes

This PR can be followed by experiments with Gluttons on Kusama to
confirm that the timeout is sufficient.

[Release/CI] Github flow to build `polkadot`/`polkadot-parachain` rc binaries and deb package (#5963)

This PR introduces a GitHub flow, that should replace a semi manual part
of the release process to build rc binaries for `polkadot` and
`polkadot-parachain` + the `polkadot` deb package.

Right now, this part of the release is done on the `cleanroom` machine
by the release engineers via triggering bash scripts directly on the
server. These GitHub flows should replace it and move everything to the
CI.

The whole flow is meant to be run in the new
[paritytech-release](https://github.com/paritytech-release) where the
automated release is going to be moved.

The flow includes the following steps:
- Build `polkadot`, `polakdot-prepare-worker`, `polkadot-execute-worker`
and `polkadopt-parachain` binaries
- Sign those artefacts using `gpg` and generate a sha256 checksum
- Build deb package for `polakdot`
- Make a GitHub attestation
- Upload artefacts to the S3 buckets

Closes: https://github.com/paritytech/release-engineering/issues/223

---------

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

PR removes short-benchmarks from GitLab, adds condition for
cargo-check-rutimes

Disable flaky tests reported in:
#5972 
#5973 
#5974