Panic when subscription is canceled

[tzdybal]

panic: close of closed channel

goroutine 881 [running]:
github.com/celestiaorg/optimint/rpc/json.(*service).Subscribe.func1()
	github.com/celestiaorg/optimint@v0.3.0/rpc/json/service.go:134 +0x33c
created by github.com/celestiaorg/optimint/rpc/json.(*service).Subscribe
	github.com/celestiaorg/optimint@v0.3.0/rpc/json/service.go:111 +0x3fb

[jbowen93]

Error happens here https://github.com/celestiaorg/optimint/blob/main/rpc/json/service.go#L134

Definition of func close(c chan<- Type):

The close built-in function closes a channel, which must be either bidirectional or send-only. It should be executed only by the sender, never the receiver, and has the effect of shutting down the channel after the last sent value is received. After the last value has been received from a closed channel c, any receive from c will succeed without blocking, returning the zero value for the channel element. The form

x, ok := <-c
will also set ok to false for a closed channel.

My quick reading of this code makes me think that we should never be calling this per the above description:

It should be executed only by the sender, never the receiver

[tzdybal]

This is partially fixed by #434.

The place of panic is the only place where channel is closed. After closing the channel, loop exits, so double-close shouldn't happen inside the loop.
But because of incorrect error handling (fixed by exiting the loop here), entire serveJSONRPCforWS method could be executed more than once.

Actually, even after #434 the logic is invalid, as multiple requests can be sent via WS, causing multiple calls to serveJSONRPCforWS, thus multiple calls to close.

[tzdybal]

TBH, there's no reason for us to close this channel. In this case, leaving this for garbage collector seems to be best approach.
I'll prepare a fix.

See also: https://groups.google.com/g/golang-nuts/c/pZwdYRGxCIk/m/qpbHxRRPJdUJ