Performance Tests Workflow: Use latest WP branch for release tests

[ockham]

Description

Supersedes #32244.

As @youknowriad mentioned in Slack:

[R]elease perf jobs are breaking https://github.com/WordPress/gutenberg/runs/2676154517?check_suite_focus=true. If I have to guess, I think it's because the base WP install used comes from trunk and the fixes for the conflicts introduced so solve the conflicts are not included in both the previous release's branch and wp/5.7 branch. Ideal fix would be to rely on the 5.7 (previous wp release) as base branch instead of latest trunk like all the e2e tests jobs.

Turns out the performance script has a --tests-branch arg that is already used to set the branch from which we run the WP env for those tests:

gutenberg/.github/workflows/performance.yml

Line 44 in 45e1997

run: ./bin/plugin/cli.js perf --ci $GITHUB_SHA trunk --tests-branch $GITHUB_SHA

It's used at

gutenberg/bin/plugin/commands/performance.js

Lines 231 to 241 in 45e1997

	if ( !! options.testsBranch ) {
	log(
	'>> Fetching the ' +
	formats.success( options.testsBranch ) +
	' branch'
	);
	await git.checkoutRemoteBranch(
	performanceTestDirectory,
	options.testsBranch
	);
	}

(and below).

How has this been tested?

We'll only really know once we release the next GB version.

[mcsf]

Let's give it a go.

[youknowriad]

I think I disagree with this one :) That's not what I suggested, I think we should always use "trunk" for the performance tests themselves, the issue is with the base branch used in the docker container which means we'll get a recent WP install (trunk) with all the new APIs with an old Gutenberg plugin wp/5.7 branch causing conflicts. I think @mcsf's PR solves that.