E2E test - Pipeline with image:pull_policy for docker images

Description of the test

New E2E test for CI new keyword image:pull_policy

Verify:

• When policies are allowed allowed_pull_policies = [if-not-present always never]
  • With [always] policy job log shows Pulling docker image ruby:2.6 - https://gitlab.com/gitlab-org/gitlab/-/quality/test_cases/367154
  • with [always if-not-present] policy job log shows Pulling docker image ruby:2.6 - https://gitlab.com/gitlab-org/gitlab/-/quality/test_cases/368857
  • with [if-not-present] policy job log shows Using locally found image version due to "if-not-present" pull policy - https://gitlab.com/gitlab-org/gitlab/-/quality/test_cases/368858
  • with [never] policy there is no message with content Pulling docker image in job log - https://gitlab.com/gitlab-org/gitlab/-/quality/test_cases/368859
• When policies are not allowed - only allowed_pull_policies = [never]
  • using [always] policy job failed with error message ERROR: Preparation failed: the configured PullPolicies ([always]) are not allowed by AllowedPullPolicies ([never]) - https://gitlab.com/gitlab-org/gitlab/-/quality/test_cases/368853

Related to #364849 (closed)

Checklist

• Confirm the test has a testcase: tag linking to an existing test case in the test case project.
• Note if the test is intended to run in specific scenarios. If a scenario is new, add a link to the MR that adds the new scenario.
• Follow the end-to-end tests style guide and best practices.
• Use the appropriate RSpec metadata tag(s).
• Ensure that a created resource is removed after test execution. A Group resource can be shared between multiple tests. Do not remove it unless it has a unique path. Note that we have a cleanup job that periodically removes groups under gitlab-qa-sandbox-group.
• Ensure that no transient bugs are hidden accidentally due to the usage of waits and reloads.
• Verify the tags to ensure it runs on the desired test environments.
• If this MR has a dependency on another MR, such as a GitLab QA MR, specify the order in which the MRs should be merged.
• (If applicable) Create a follow-up issue to document the special setup necessary to run the test: ISSUE_LINK
• If the test requires an admin's personal access token, ensure that the test passes on your local environment with and without the GITLAB_QA_ADMIN_ACCESS_TOKEN provided.