E2E tests: wait for MRs to be prepared

What does this MR do and why?

Resolves #416217 (closed)

MR preparation steps: https://docs.gitlab.com/ee/api/merge_requests.html#preparation-steps

This MR makes use of the prepared_at field on merge requests. In the E2E tests we sometimes create MRs via the API and then immediately visit/edit them in the UI. This can cause automated tests failures as the UI is requesting the diff before it is ready, which can affect which fields are displayed, for example: #416217 (closed)

I think waiting for preparation is OK as users would be unlikely to navigate to an MR so soon after creation via the API. Testing locally, MRs took between 0.5s and 1.5s to be prepared.

This MR makes sure the MR is prepared before opening an MR in the UI. It also de-quarantines a test which was failing intermittently since it was navigating to the edit page before the MR was prepared.

I also think it is beneficial to have an explicit check that MRs are being prepared correctly as it can cause all types of strange behaviours in the UI if they aren't.

How to set up and validate locally

This test will create an MR via the API: QA_LOG_LEVEL=DEBUG QA_GITLAB_URL=http://192.168.4.31:3000 bundle exec rspec qa/specs/features/ee/browser_ui/3_create/repository/assign_code_owners_spec.rb

The issue we are trying to avoid can be observed by the following:

1. Just before creating to the MR -> http://192.168.4.31:3000/admin/background_jobs -> Busy tab -> stop all (stopping this process will stop diffs being generated)
2. Create the MR and then navigate to the edit page for the MR
3. Code owner approval is required will be missing from the MR edit page

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.