[CI] Hoist the platform/arch independent test build into its own job

[jashook]

This will leverage the work in #33066 to create a job to build the platform independent tests on one machine and reuse them. This reduces our azure usage by not duplicating the test build by arch and increases latency by using OSX as the build machine.

Requires #33072 and #34507 to be complete.

[sdmaclea]

Requires #33072 and #34507 to be complete.

The #34507 implementation bypassed #33072. I don't think it is a required here either.

[sdmaclea]

Is there any preference which platform builds the targetGeneric tests?

• My guess is that test will build fastest on OSX based simply on watching the order CI completes.
• OSX may have lower total machine availability
• OSX might be under utilized
• OSX may uncover more tests which we thought were targetGeneric, but were not actually.

Editted:

I just reread the top post.

using OSX as the build machine.

[jashook]

/cc @trylek

[sdmaclea]

This note is in eng/pipelines/coreclr/templates/build-test-job.yml

### TODO: As of today, build of managed test components requires the product build
### as a prerequisite due to dependency on System.Private.Corelib. After switching
### over to its reference assembly we should be able to remove this dependency and
### run managed test builds in parallel with the product build job.

There is a small finite set of tests which depend on internal APIs in System.Private.Corelib. I think this set is ~10 tests. They are controlled by a meta-data flag which I don't remember, but @AndyAyersMS pointed me to in 2017-18. I am not sure a reference assembly would be sufficient.

This may reduce the benefit of this change.

Ultimately we really want an early and a late test build set. The tests which depend on System.Private.Corelib should be placed in the late set, but that is a separate piece of work. It seems it could easily be a later refactoring.

I think it is probably worth going ahead with fixing #34508 w/o this refinement.

[jashook]

/cc @trylek, he should have interesting opinions :)

[trylek]

I agree that the build split into "targetSpecific" vs. "targetGeneric" tests supersedes the previous plan to build tests against reference assembly for S.P.C so I agree with Steve that the splitting can be easily carried out without that and we can probably forget about the S.P.C. reference assembly plan completely in light of this broader refactoring.