Change newest_first default source filter behavior

What does this MR do and why?

Change the newest_first method default source filter behavior

#565623 (closed)

Why?

With !189704 (merged), I filtered all of the pipelines whose source wasn't a :push source. This assumption caused issues with users who trigger or change the latest pipelines using the API, e.g. https://docs.gitlab.com/api/commits/#set-the-pipeline-status-of-a-commit. The previously mentioned API can change the status of a pipeline, causing the source to be :external, which makes sense, but this prevents the MRWidget from showing the latest pipeline section.

Why not add the pipeline source to the API?

Because there are multiple cases that we might miss, and the initial bug that prompted the change to newest_first was about pipeline schedules changing the latest pipeline ID consistently

Screenshots or screen recordings

Before	After

How to set up and validate locally

1. Create a project and create a new branch
2. Make some changes in the branch and create a merge request
3. Merge into the target branch.
4. Call the commit status API to create a pipeline, update the status to running and successful, for example

curl --request POST \
--header "PRIVATE_TOKEN:<pat-token>" \
--url "http://gdk.test:3000/api/v4/projects/<project_id>/statuses/<sha>?state=running"

5. When you check the merge request via https://gitlab.example.com/api/v4/projects/:project_id/merge_requests/:mr_id, you will see that pipeline.source is external. For instance

curl --request GET \
--header "PRIVATE_TOKEN:<pat-token>" \
--url "http://gdk.test:3000/api/v4/projects/<project_id>/merge_requests/<mr_id>"

1. On the Merge Request overview page, merge pipeline should show up

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.