Disable "connected peers" and "peer info" protocols.

[shamil-gadelshin]

This PR temporarily disables connected-peers and related peer-info protocols for debugging purposes. It also disables the NotificationReason::WentOnlineSubspace for subspace-service.

Code contributor checklist:

• I have read, understood and followed contributing guide

[nazar-pc]

I understand and agree with the end result here, but I think there is a cleaner way to achieve the same goal.

For example, instead of physically removing code and adding dead code suppressions, we could simply set target and limit of connected peers to 0. In this case it will not keep any connections alive, which has the same exact result as what this PR does with a much smaller and cleaner change.

For peer info protocol, I'm not exactly sure why we need to remove it either. If we identify that connected peers protocol wasn't an issue, it would be beneficial for peer info to still be supported by network participants such that upgraded peers can maintain connections with them again once we re-enable the protocol.

[shamil-gadelshin]

For example, instead of physically removing code and adding dead code suppressions, we could simply set target and limit of connected peers to 0. In this case it will not keep any connections alive, which has the same exact result as what this PR does with a much smaller and cleaner change.

Setting those limits to zero would not exclude the "unknown influence" of the feature that can cause problems. Commenting and restoring the code doesn't cost much but makes the test much clearer.

For peer info protocol, I'm not exactly sure why we need to remove it either. If we identify that connected peers protocol wasn't an issue, it would be beneficial for peer info to still be supported by network participants such that upgraded peers can maintain connections with them again once we re-enable the protocol.

It seems that peer-info protocol maintains an expected connection sometimes. It wasn't the case to the best of my knowledge before the last libp2p upgrade. I didn't have time for debugging the issue yet which we should do next. I disabled it to remove the possible influence because we don't use peer-info protocol without connected-peers protocol.

[nazar-pc]

Setting those limits to zero would not exclude the "unknown influence" of the feature that can cause problems. Commenting and restoring the code doesn't cost much but makes the test much clearer.

You wrote the code, you can trace what is being used and what isn't when value is set to 0. I do not understand what you're worrying about.

It seems that peer-info protocol maintains an expected connection sometimes. It wasn't the case to the best of my knowledge before the last libp2p upgrade. I didn't have time for debugging the issue yet which we should do next. I disabled it to remove the possible influence because we don't use peer-info protocol without connected-peers protocol.

If you don't understand how it happens, why changing in this PR then? Leave it alone the way it is until you understand what it does. The only reason it would keep connection alive is to make a request, after that it should not prevent connection from shutting down unless we keep the stream alive for some other reason.