Workflows: use native for community tests in CI

[kitbellew]

No description provided.

[kitbellew]

@tgodzik @jchyb i was working on this purely out of curiosity, and i don't understand the results. if you compare this latest test run using native (forgetting for a second that it failed), it is slower than the previous run which used jvm:

native: https://github.com/scalameta/scalafmt/actions/runs/13086461314
jvm: https://github.com/scalameta/scalafmt/actions/runs/13085684687

native build takes 8 minutes, jvm a little over 1.

jvm test of scala3: 11 minutes (https://github.com/scalameta/scalafmt/actions/runs/13085684687/job/36516501088)
native test of scala3: 16 minutes (https://github.com/scalameta/scalafmt/actions/runs/13086461314/job/36518171422)

so, native is only 2 minutes faster, excluding the build step, which is hardly earth-shattering. both use the same approach, which includes futures for parallelism. i wonder...

[tgodzik]

I wouldn't expected a large difference without anyone more competent than me looking into optimizing it. Though, shaving off 2 minutes is still good in my book. It's not so useful if you have to build the native binaries yourself.

Potentially, we could build the binaries, upload them and download to run on a specific suite.

[jchyb]

It should be a little faster after merging #4789 (the previous very positive looking comparisons were made using 2.12, where that library was not necessary), but there's not much we can do about the long build times if we want to keep the runtime fast.

[kitbellew]

It should be a little faster after merging #4789 (the previous very positive looking comparisons were made using 2.12, where that library was not necessary), but there's not much we can do about the long build times if we want to keep the runtime fast.

i will review it, and it's generally useful, but we switched to using futures, so it will not have effect but perhaps we could review how we use futures.

[jchyb]

Ah, I see, it might not improve things much then