Update CFS and other OneBranch tooling

[andyleejordan]

In the course of debugging why we couldn't so much as cargo install tree-sitter-cli I discovered a number of issues resolved in this PR.

For the msrustup toolchain, ms-stable stopped being supported in 2024, meaning under the covers we've just been using ms-prod-1.88. I've updated the OneBranch pipelines to specifically use ms-prod-1.93. The OneBranch documentation recommends a specific pin, and not e.g. ms-prod. They also recommend using a rust-toolchain.toml file, but that gets a bit in the way of our existing logic which detects and uses msrustup only when available.

I've switched us from the mscodehub CFS feed to a new dedicated DSCCargoMirror CFS feed in msazure. By not being cross-org, we don't have to deal with complicated authentication with a service connection, and can just rely on the CargoAuthenticate task. I know of no compelling reason to stick to the mscodehub feed when we can eliminate a lot of headache here.

If and when as a dev you cannot update the feed, there is a very hidden button titled "Allow externally-sourced versions" available only after going to the feed and searching the upstream sources for a package. I've found it sometimes just gets turned off, which then prevents us from adding packages to the feed, and this will appear as an authentication failure. Authenticating locally with either artifacts-cargo-credprovider or msrustup does indeed work, but that setting must be toggled on.

I removed ob_restore_phase: true as that was an old workaround for accessing network resources that were not allow-listed, and it messed up the timing of the tasks. Seems like it was put there because we were errantly adding a second checkout: self task (it's an additional since the OneBranch template already does that). With that gone, ordering is fine and signing and CodeQL is happy.

We also weren't passing through -UseX64MakeAppx when we migrated the MSIX build function, and that needs to happen for one of the OneBranch builds.

[andyleejordan]

Watching the OneBranch run, it failed on Windows only at the signing step due to the internal service timing out, so I think this is at least good to go for review.

Edit: found the reason for that, and for the previously added ob_restore_phase workaround. For some reason we had checkout: self on the Windows build, while the OneBranch template already does that. So we were checking out twice which trips up signing and CodeQL validation steps.

[andyleejordan]

Last thing is symbols and uh, fixing the path highlighted that this wasn't working in the first place. Went back and looked at a "successful" build...

Linux

Source indexing is not supported on this OS.
Found 0 files.

macOS -- N/A

Windows

Found 0 files.
##[warning]No files selected for indexing.

[andyleejordan]

Assigning reviewers now as that's a green build. I still don't think the Windows symbols are source mapped but that's a different investigation.

[andyleejordan]

By the way this is a follow-up to #1410 as I needed the OneBranch pipeline to work again so I could get the MSIX, RPM, and DEB packages and verify them.

[andyleejordan]

Nope, one more thing to fix. MSIX bundle is getting created under debug.

[andyleejordan]

Bingo, MSIX bundle now exists too.