Move ssh session helper function to api/sshutils

[Joerger]

In a follow up PR, I plan on providing extra session parameters via client.OpenChannel("session", sessionParams). Before making these changes with no relation to the api/observability/tracing/ssh package, I wanted to move these helper functions to a more ubiquitous location.

[rosstimothy]

I don't think we should be exposing the crimes from the tracessh package in a generic ssh helper package. Can we keep this internal to tracessh and extend tracessh with any additional receiver methods to achieve the desired behavior?

[Joerger]

I don't think we should be exposing the crimes from the tracessh package in a generic ssh helper package. Can we keep this internal to tracessh and extend tracessh with any additional receiver methods to achieve the desired behavior?

This isn't really tracing related at all - this is the session request callback logic added in #42123 to support the server->client "current-session-id@goteleport.com" request. It was only added in the tracing package for its proximity to the lowest level sshclient.NewSession call. I should have included this in the PR description for clarity.

exposing the crimes from the tracessh package

This portion is moreso covering a missing component of the x/crypto/ssh package in giving the consumer the ability to handle session requests on the crypto/ssh.Session. I think this commit might shed light on what I mean, as it cleans up the logic a bit to mirror the HandleChannelOpen logic offered by the crypto/ssh package for global channel requests, which it does not offer for session requests.

Let me know if you'd still just like this isolated to the tracing package.

[Joerger]

@rosstimothy I forgot to mention, the main motivation behind this is actually this change, which further needs to work around the limitations of the x/crypto/ssh package.

[rosstimothy]

I think it would be more appropriate to use the tracessh.Client directly over an ssh.Client if possible, and add a new API to the tracessh.Client to support this use case. Most of our clients today use tracessh so that we get trace coverage on all requests so we should prefer that where possible.

If that's not possible I think it'd make more sense to leverage a copy of this closer to where you actually need it rather than exposing this in an SSH package in the API module.