refactor!: simplify UtpSocket api

[morph-dev]

Remove accept/connect in favor of accept_with_cid/connect_with_cid (which are renamed to accept/connect).

This is needed in order to fix ethereum/trin#1596, which will be done in future PR.

Also simplified tracking of accepted and incoming connections: using HashMapDelay instead of HashMap+HashSetDelay combination.

[KolbyML]

So we are dropping support for using uTP as a standard replacement for TCP? *_with_cid's are non-standard api's and are specific to our usecase. If we are dropping support for standard interfaces for using uTP as a replacement for a TCP socket, I think we should have a statement in the readme about it. To document to people who may want to use the library as we would no longer support the assumed interface, hence our library could probably no longer be used by 3rd party's not building a Portal client. As the whole connect_with_cid thing we do is quite unique to our project ie portal, I feel like at that point our uTP crate is not really usable to others.

I kind of feel against this change, as it is removing pretty base functionality for a uTP library. Yes we don't use the standard connection/accept interfaces, but that is more of a we do a very custom thing. If you are publishing this as a library to crates.io, I think we should support the standard uTP interface and not drop it because we don't use it.

I won't block this of course if others support removing this functionality, but it tastes a little off is all. Publishing a uTP crate with an interface only a Portal client would use, at that point it might make sense to move this crate into the Trin repo and call it trin-utp as only Trin will be able to use it.

If we go down the path of making this library Portal specific/specialized and merge this PR, I think we should also remove support for running this crate over UDP, as with us removing this API the library isn't really usable directly over UDP anymore

[KolbyML]

Also I would argue that this isn't a refactor as it is removing functionality, it is a feat

[KolbyML]

https://github.com/ikatson/rqbit A Rust Bittorrent client is likely to use uTP. I think it would be great if we could collaborate on 1 codebase and make it really good.

If we removed connect/accept as done in this PR projects like rqbit wouldn't be able to use ethereum/utp, and instead be forced to build there own uTP or add this connect/accept api back.

[KolbyML]

Here is an issue on uTP ikatson/rqbit#277 I think we should collaborate with them

[morph-dev]

I didn't know initially how to preserve this functionality and fix the bug. But now I think I know a way, so I will give it a try.
Closing this PR.