check-publish-compile must be able to simulate release for a single prdoc

[iulianbarbu]

Currently check-publish-compile when running in the context of a PR aims to simulate the PR release following the reasoning below:

1. runs a round of plan and apply --registry without the PR's prdoc to simulate a release happening before the PR, as if the base branch is a fresh new release and the PR is a patch we want to apply
2. then simulate the patch "release" of the PR (based on the bumps from its prdoc) on top of the updated polkadot-sdk's Cargo.toml (updating it even more based on the bumps from the PR) , after running through step 1.

excerpt from check-publish-compile

      - name: set current PR's prdoc name in a variable
        env:
          GITHUB_PR_NUM: ${{ github.event.pull_request.number }}
        run: |
          echo "CURRENT_PRDOC=pr_${GITHUB_PR_NUM}.prdoc" >> $GITHUB_ENV

      - name: parity-publish update plan w/o current prdoc
        run: |
          if [ -f prdoc/$CURRENT_PRDOC ]; then
            mv prdoc/$CURRENT_PRDOC .
          fi
          parity-publish --color always plan --skip-check --prdoc prdoc/

      # The code base is not in master's state (due to commits brought by the
      # current PR), but we're interested in all master's prdocs to be applied
      # as if master is a stable branch, and in next steps we're following up with
      # a patch release of all crates based on some newly added prdocs
      # (meaning only the current prdoc).
      - name: parity-publish apply plan on the code state prior to current prdoc
        run: parity-publish --color always apply --registry

      - name: move all prdocs except current one to unstable dir
        run: |
          if [ -f $CURRENT_PRDOC ]; then
            mkdir prdoc/unstable
            mv prdoc/pr_*.prdoc prdoc/unstable
            mv $CURRENT_PRDOC prdoc
          fi

      - name: parity-publish update plan just for PR's prdoc
        run: |
          if [ -f "prdoc/$CURRENT_PRDOC" ]; then
            parity-publish --color always plan --skip-check --prdoc prdoc/
          fi

      - name: parity-publish apply plan
        run: |
          if [ -f "prdoc/$CURRENT_PRDOC" ]; then
            parity-publish --color always apply --registry
          fi

      - name: parity-publish check compile
        run: |
          packages="$(parity-publish apply --print)"

          if [ -n "$packages" ]; then
            cargo --color always check $(printf -- '-p %s ' $packages)
          fi

This way we try to ensure that we don't miss to bump crates relevant to the PR changes, but it is not 100% accurate based on recent experience. Some notes:

1. the check can start failing when we backport into master the node versions (in code) and move the prdocs released with the latest stable release into a dedicated directory, outside of the scope of any check-publish-compile run on any of the following PRs (cc @EgorPopelyaev (not sure if you noticed this with your backport PRs). One of the reason why this is: Bump pallet-staking-reward-fn #10905 (comment)

2. I noticed in the past the check failing when backporting PRs from master to a stable branch (to be released in a patch release for that stable version). For those failures, I haven't investigated why they happened, but could be the same reason.

ACTION ITEMS:

1. Investigate check-publish-compile as a release engineer and determine if it resembles the release flow of a stable/patch release.
2. If we decide check-publish-compile should help prevent issues during releases based on 1., we must investigate when check-publish-compile starts to fail based on the past commits and the failure, and decide appropriate actions to either improve the check, or improve parity-publish