Allow sni version override for testing

[mdaigle]

When we make changes to SNI, it's important to test the changes in combination with MDS to avoid regressions. This PR adds the ability to trigger a pipeline run with an overridden SNI version pulled from the internal validation feed in ADO. This functionality is only available to pipeline runs within the ADO.Net project in ADO. Pipeline runs within the public project do not have access to the internal feed and will fail if an override version is set.

Proof that runs fail in public pipelines when sni override is set:
Project: https://sqlclientdrivers.visualstudio.com/public/_build/results?buildId=109913&view=results
Package: https://sqlclientdrivers.visualstudio.com/public/_build/results?buildId=109914&view=results

[paulmedynski]

Looks good, just a few nitpicks.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 72.80%. Comparing base (17cb0b0) to head (2702322).
Report is 14 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3184      +/-   ##
==========================================
- Coverage   72.96%   72.80%   -0.16%     
==========================================
  Files         283      285       +2     
  Lines       58997    59137     +140     
==========================================
+ Hits        43048    43057       +9     
- Misses      15949    16080     +131     

Flag	Coverage Δ
addons	92.58% <ø> (ø)
netcore	75.53% <ø> (-0.20%)	⬇️
netfx	71.15% <ø> (-0.21%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[benrr101]

I think you and I should have a bit of a conversation about when and how the handful of components need to be tested together (MDS, SNI, AKV, MSS, ETC, WTF, BBQ). I want to get a better idea what depends on what and how the pipelines should be constructed to handle those situations. It's nothing that needs to block this specific PR, but since I think we will want to rebuild this pipeline as part of other engineering goals, I think we'll want to discuss it at some point.

[benrr101]

After spending so much time on the AKV pipeline, I've got a lot of preferences about style for pipeline yaml. On the one hand, I could lay it all out in this PR and make things annoying. On the other hand, I anticipate rewriting this pipeline as well, and we can hold off on stylistic changes until then. Which would you prefer?

[mdaigle]

If you're ok with waiting, I'd prefer that. I don't anticipate this to be a long term solution. I had other approaches in mind to facilitate SNI testing, but they were blocked on this pipeline migrating to onebranch. My idea was to keep this small and easily removable.

I'd also be happy to standardize on an IDE and formatter for yaml. Raw yaml editing is not the way to go.