Additional Disconnect Handling

[amtelekom]

• Allow Server Handle to trigger Disconnect
• Allow Client Handler to read Disconnect reason

[Eugeny]

I think the naming of Handler::disconnect is going to be confusing for the users - just today there was a user wondering how to react to session closure due to an error. Most will probably assume that it's going to be called when the session is closed for any reason - what do you think?

[Eugeny]

Otherwise LGTM

[amtelekom]

I see the problem. I would still use the word disconnect, since that's what RFC 4253 calls it.

I can see 2 Variants:

• prefix it with received_ to hopefully make more clear we're just talking about a normal session end (22373e5)
  This now opens up the possibility to add a disconnect or connection_closed callback that is called if the main tokio::select! loop is left for any reason, or users can parse the result of the join. (

• Pipe all kinds of disconnects through the disconnected handler (2e39628). Since the error isn't Clone and a borrow to it wouldn't be Sync, we have to move the Error through the callback in this case though.

[Eugeny]

The 2nd variant is much clearer to the user and is universal, I like it! 👍 👍

Now just to remove this comment https://github.com/warp-tech/russh/pull/255/files#diff-a54f5b4b2c7b6955dd496e3f9b7bcc52dac6226eb3450c4785bd7957e47f0c1dR1694 and the PR is good to go

[amtelekom]

Fixed & squashed

[Eugeny]

Thanks - appreciate you working on these things ✌️