Consider deprecating servicing branches and use only main

[matouskozak]

To decrease maintance cost of xharness, we could simplify our servicing support infrastructure by using main branch only.

• [ ] Rewire maestro subscription and run dotnet/runtime (and other repos) out of dotnet/xharness main only and observe any issues
• [ ] If everything works as expected, stop creating new servicing branches for future release
• [ ] Cleanup test apps as we have duplicite entries due to servicing using different paths

[matouskozak]

@akoeplinger @lewing @premun Do you know about anything that could bites us back if we stop having servicing branches for xharness? From the mobile side of things, we use the same mobile helix queues across servicing and main in runtime, I'm not sure there is much added benefit for having servicing branch of xharness.

[premun]

I think it was mainly created so that we can stop thinking about release branches of dotnet/runtime and dotnet/arcade.

If you change XHarness CLI arguments then:

• dotnet/arcade has the Helix SDK which calls it
• dotnet/runtime have their own custom wrappers around XHarness too

So I think it's mostly about that

[akoeplinger]

Should be fine. The only thing that we need to pay attention to is https://github.com/dotnet/runtime/blob/6aecb65a7eff3e91dd6b8856401854e03c30a839/src/mono/wasm/symbolicator/WasmSymbolicator.csproj#L4-L7 which is loaded into the xharness process via --symbolicator argument and we've had issues in the past when different/incompatible framework versions were used (that said, if we run into problems there we could just not support --symbolicator on 8.0/9.0 branches)