CI: move [publish_documentation] to the start [master_branch] pipeline

Context

Fixes: #5759 (closed)

Move the job publish_documentation to the start master_branch pipeline

This helps to ensure that this job is not interrupted by subsequent merges to the master branch.

We do this by setting needs: [] instead of re-ordering the stages. Re-ordering stages would affect other pipelines as well.

I've also added a slight refactoring of scripts/ci/doc_publish.sh. See the commit message for the rationale.

Manually testing the MR

I've created an artificial master_branch pipeline here: https://gitlab.com/tezos/tezos/-/pipelines/885854700

As you can see by inspecting the pipeline with vizpl2, the publish documentation now starts right away:

vizpl2 --graph tezos/tezos#885854700

(NB: the screenshot above was taken of the pipeline while running, so durations are not representative. Also, the publish_documentation job is much quicker here, because it doesn't actually build nor push the documentation. However, it demonstrates that it starts early.)

---

This was done using the tools in pipeline-profiler. Running ./scripts/run_pipeline_type.sh as detailed below in a checkout of this branch will produce a pipeline like the one above.

In more detail (from the root of at the checkout of this MR):

git clone git@gitlab.com:tezos/pipeline-profiler.git /tmp/pipeline-profiler
PRIVATE_TOKEN=glpat-... /tmp/pipeline-profiler/scripts/run_pipeline_type.sh master_branch

This requires a GitLab access token with the scope of api.

It will create an artificial master_branch pipeline. It is artificial in the sense that it does not actually run on the master branch. It will run on the branch of this MR. But it will contain the same jobs as the master_branch does. A normal master_branch pipeline do some privileged actions, like publishing documentations and docker images. The artificial branch will do all the work (build images and building documentation), but will not actually publish anything.

Checklist

• Document the interface of any function added or modified (see the coding guidelines)
• Document any change to the user interface, including configuration parameters (see node configuration)
• Provide automatic testing (see the testing guide).
• For new features and bug fixes, add an item in the appropriate changelog (docs/protocols/alpha.rst for the protocol and the environment, CHANGES.rst at the root of the repository for everything else).
• Select suitable reviewers using the Reviewers field below.
• Select as Assignee the next person who should take action on that MR