Add ability to send posix/ansi signals in SshCommand

[Levi--G]

I noticed SshCommand does not have a method for sending signals although it is supported by the channel and underlying system.

This code:

• Parses the Signal
• Sends the Signal using the preexisting method

All signals listed in https://datatracker.ietf.org/doc/html/rfc4254#section-6.9 are supported and use their libc compatible values in case someone needs conversion from libc.

Still missing are tests, but i don't understand the test project structure, if someone could help me out there that would be great.

[Rob-Hague]

Looks reasonable at first glance. Hopefully CONTRIBUTING.md at the repo root will answer any questions about tests (if not then maybe it can be improved). test\Renci.SshNet.IntegrationTests\SshClientTests.cs (or test\Renci.SshNet.IntegrationTests\OldIntegrationTests\SshCommandTest.cs) would be suitable places for basic integration test. Don't think this change needs extensive testing

[Rob-Hague]

Is this list exhaustive? I am thinking not based on the penultimate paragraph of 4254 section 6.10:

Additional 'signal name' values MAY be sent in the format
"sig-name@xyz", where "sig-name" and "xyz" may be anything a
particular implementer wants (except the "@" sign).

I think it would be more future-proof to have SendSignal(string) rather than SendSignal(enum). This type could still exist as a static class for discoverability e.g.

public static class CommandSignals
{
    /// <summary>
    /// Hangup (POSIX).
    /// </summary>
    public const string HUP = nameof(HUP);
}

Similar to https://learn.microsoft.com/dotnet/api/system.net.mime.mediatypenames

[Levi--G]

You are right, that would be better, I will adjust them. I propose we prepend the SIG then so its:
public const string SIGHUP = "HUP";
Would that be ok?

[Rob-Hague]

Suggested change

	/// <exception cref="SshOperationTimeoutException">The operation timed out.</exception>
	/// <exception cref="InvalidOperationException">The size of the packet exceeds the maximum size defined by the protocol.</exception>

[Levi--G]

Why exactly would these be removed? They are exceptions from the underlying ssh calls.

[Rob-Hague]

let's drop this and stick with just SendSignal

[Levi--G]

I think there is some benefit of having a TrySendSignal though, it can be used as a last resort to send to every command started upon something happening like a server going down or similar without having to catch all the exceptions or doing all the checks yourself (some of which you don't even have access to).
channel.IsOpen for instance will cause an exception in SendSignal, but is impossible to check outside the class, leaving no option but to catch exceptions if that would be the case. Exceptions should be exceptional and methods that are prone to throwing should have Try variants according to ms documentation and best practices: https://learn.microsoft.com/en-us/dotnet/standard/exceptions/best-practices-for-exceptions