Do not trigger post-merge jobs for cross-project pushes

Do not trigger post-merge jobs for cross-project pushes

We need to avoid double-triggering of post-merge jobs in the following
scenario:

 1. A private MR gets merged into the private BIND 9 repository.

 2. This merge operation triggers a "push" pipeline in the private
    repository, which correctly runs post-merge jobs, e.g. to set MR
    metadata in the private project.

 3. When a release is published, a script is run to change the
    automatically assigned milestone value ("Not released yet") to
    something else.

 4. Shortly afterwards, the result of the merge from step 1 is merged
    back into a maintenance branch in the public repository.

 5. The push operation triggers another "push" pipeline, this time in
    the public project.

At this point there are two problems:

  - If the script is dumb (like it currently is), it will extract the
    merge request ID from the merge commit description and change the
    milestone for a merge request in the wrong project namespace.

  - Even if the script was fixed to extract and use the correct GitLab
    project reference, it would reset the milestone for the merge
    request in the private repository back to "Not released yet" - while
    the milestone set in step 3 should be retained.

An alternative would be to change the order of operations so that
post-release milestoning happens at a later stage, while also fixing the
script to correctly follow cross-project references, but that approach
seems more fragile than simply failing on all cross-project pushes.  The
rule to enforce is: each project should only take care of its own
post-merge tasks.

(cherry picked from commit 60140607740bf8e07c0f223c18798bef36ef439c)