Consider forbidding new connection establishment on eureka clients

[DimitrisJim]

Discussed during initial audit and opened to keep track as point to be discussed.

Current flow as discussed does allow for a new connection/channel to be built upon a client intended for ibc eureka. We should be able to look-up for the existence of a counterparty stored as a way to forbid new connections being created on a given client id.

This should make the phasing out of classic handling more clear cut considering the separation of clients.

ibc-go team will handle this issue.

---

For Admin Use

• [x] Not duplicate issue
• [x] Appropriate labels applied
• [ ] Appropriate contributors tagged/assigned

[colin-axner]

If we want to force eureka by default but still support classic ibc behaviour (connection/channel handshakes). We could simply remove MsgConnOpenInit, allowing a latest version chain to use eureka on its end, but still create a classic connection to the counterparty

[AdityaSripal]

I really don't think this is necessary especially since I think existing clients supporting Classic should be allowed to support Eureka.

Though perhaps we don't want new connections built on top of clients intended for Eureka. In this case, I think @colin-axner 's suggestion makes sense.

Either way, I would give this low priority; get input from the product team in terms of what makes the most sense for the rollout and then do right before release if we decide to do it.