Reorder CI build processing to prevent bypass of Deployment Approvals

What does this MR do and why?

In order to prevent some builds from bypassing Deployment Approvals, we need to check if there is a deployment that should be blocked before checking build.schedulable? and build.actionable?.

See !75710 (comment 756445822) for context.

Part of Deployment Approvals MVC: #343864 (closed)

How to set up and validate locally

1. Enable the deployment_approvals feature flag.

Feature.enable(:deployment_approvals)

2. Set up a project to deploy to an environment. Example job from .gitlab-ci.yml:

production:
  stage: deploy
  script:
    - echo done
  environment:
    name: production

To test an actionable build, add:

when: manual

To test a schedulable build, add:

when: delayed
start_in: 1 minute

3. Protect the environment being deployed to. See https://docs.gitlab.com/ee/ci/environments/protected_environments.html#protecting-environments.

4. Add a required approval to the protected environment that was just created:

ProtectedEnvironment.last.update(required_approval_count: 1)

5. Start a pipeline. The production job should be in a blocked state.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.