PR Summary

Implementation of #13282

PR Context

This PR adds the -SSHTransportPath parameter to allow specification of a custom ssh executable. While it can be used to use a custom version of OpenSSH for compatibility or troubleshooting reasons, the primary impetus is to enable transport authors to substitute their own executables in order to provide alternative transports (such as websockets, rendevous, Azure Bastion-like services, phone-home debug sessions, etc.), since all Powershell does is spawn ssh and then pass stdin/stdout PSRemoting XML to/from the program.

This PR is intended to be as low impact and non-breaking as possible, and as such the Arguments passed to the command do not change and are not customizable, however they do provide all the information required to establish a session so a custom wrapper can translate the SSH arguments into whatever working options it requires.

This is intended as a low-impact stop gap until the PSRemoting engine is decoupled into a subsystem and a proper CustomTransportHandler interface is provided.

WIP to complete

• @PaulHigin in the case the executable is not found, it currently gets wrapped and throws a generic eventing error, is it OK to adjust the eventing error with the file not found exception?
• Tests

PR Checklist

• PR has a meaningful title
  • Use the present tense and imperative mood when describing your changes
• Summarized changes
• Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
• This PR is ready to merge and is not Work in Progress.
  • If the PR is work in progress, please add the prefix WIP: or [ WIP ] to the beginning of the title (the WIP bot will keep its status check at Pending while the prefix is present) and remove the prefix when the PR is ready.
• Breaking changes
  • None
  • OR
  • Experimental feature(s) needed
    • Experimental feature name(s):
• User-facing changes
  • Not Applicable
  • OR
  • Documentation needed
    • Issue filed:
• Testing - New and feature
  • N/A or can only be tested interactively
  • OR
  • Make sure you've added a new test if existing tests do not effectively test the code changed
• Tooling
  • I have considered the user experience from a tooling perspective and don't believe tooling will be impacted.
  • OR
  • I have considered the user experience from a tooling perspective and enumerated concerns in the summary. This may include:
    • Impact on PowerShell Editor Services which is used in the PowerShell extension for VSCode (which runs in a different PS Host).
    • Impact on Completions (both in the console and in editors) - one of PowerShell's most powerful features.
    • Impact on PSScriptAnalyzer (which provides linting & formatting in the editor extensions).
    • Impact on EditorSyntax (which provides syntax highlighting with in VSCode, GitHub, and many other editors).