Summary

Separate core IBC handlers into 3 sections:

• classic (03-connection, 04-channel)
• client (02-client)
• packet (eureka packet server)

Problem Definition

Given the redesign of core IBC, we should take a second to create an intuitive folder structure/code layout.

Proposal

core IBC should maintain it's public msg server which has:

• handshake rpc's
• packet rpc's

It should embed a classic server to handle packet v1 types and it should also embed the client server and packet server. We could choose to move the existing implementations to their respective submodules #19 (I would recommend). We would keep the core IBC msg server, but it would either embed or redirect to each implementation as appropriate. This would mean the client msgs would be implemented on the 02-client keeper. The classic 04-channel msgs would be implemented on the channel keeper and the new v2 handlers would be implemented on the packet keeper.

Given that packet v2 (multi-packet data) will be used by the packet server and will create a new ibc module callback interface, I would recommend simplifying the core IBC msg server such that it either redirects to the legacy msg server or the packet msg server. There are likely a mirage of tricks that can be used here, but generally I am hoping for something like:

func (k *Keeper) RecvPacket(goCtx context.Context, msg *channeltypes.MsgRecvPacket) (*channeltypes.MsgRecvPacketResponse, error) {
    packet := msg.GetPacket()
    if packet.IsLegacy() {
        return k.classicServer.RecvPacket(goCtx, msg)
    }
    
    return k.packetServer.RecvPacket(goCtx, msg)
}

The code layout might look like:

modules/
    core/
        keeper/
            msg_server.go
        server/
            classic/
                03-connection/
                04-channel/
                    keeper/
                        msg_server.go
            client/
                keeper/
                    msg_server.go
                types/
            packet/ // contains eureka + packet v2
                keeper/
                    msg_server.go
                types/

Optionally client can be 02-client or client-router.

In addition, I would recommend that each sub msg server also handle the application callbacks (packet server would have a port router) rather than having all the callbacks occur at the top level. The top level should be for composition of the sub components

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged/assigned
• Estimate provided