feat: connect methods' block behavior

[flavorjones]

For the methods TCP.connect, UDP.connect, HTTP.connect, POP3::Mixin#pop3_connect, and SMTP::Mixin#smtp_connect:

• return the block's return value
• TCP, UDP, POP3, SMTP: close the socket even if the block raises an exception

[postmodern]

• While I generally agree that the connection should be closed on exception, do you think there might be value in leaving it open for debugging purposes, such as if you used ruby-debug or pry?
• Would you consider this more of a bug fix or an enhancement/feature? If it's a change in behavior or new feature, then you should rebase against the 1.1.0 branch. If it's more of a bug fix, then branching off of main is fine.

[postmodern]

We might also want to add this logic to the other lib/ronin/support/network/*/mixin.rb files which define methods that will close a connection if a block is given:

• lib/ronin/support/network/pop3/mixin.rb
• lib/ronin/support/network/smtp/mixin.rb

[flavorjones]

do you think there might be value in leaving it open for debugging purposes, such as if you used ruby-debug or pry?

I don't personally see the value in leaving it open for potential debugging purposes, since a) developers can still set a breakpoint inside the block, and b) it risks a resource leak, especially if anybody is calling tcp_connect in a loop that's retrying (as in the case of a hard-to-reproduce exploit). I think the downside of having a lot of unclosed connections warrants this change.

Would you consider this more of a bug fix or an enhancement/feature

🤔 Well, I think the "return the block's value" is a feature, but closing the connection is a bugfix. If your primary concern in asking is "should this go out in the imminent 1.1.0 release or can it wait for the next minor release" I think they can both probably wait.

We might also want to add this logic to the other lib/ronin/support/network/*/mixin.rb files

OK! I will add them to this PR today. Edit: Done!

[postmodern]

I guess we could argue that this is a bug fix since we are correcting the behavior to be the "correct" behavior. I can squash merge this and queue it up for the next patch release.