Suspected race condition sending/receiving pubsub message after websocket reconnect.

#### Version information:
```
go-ipfs version: 0.4.18-
Repo version: 7
System version: amd64/linux
Golang version: go1.11.1
```

#### Type: bug
- 100% reproducible
- happy to (help) fix it.
- any advice welcome!

#### Description:

I'm building a DApp with `js-ipfs` (version 0.34.4) that interacts with a `go-ipfs` server for additional processing. I'm trying to get 1:1 connections as reliable as possible, and found the following reproducible bug...

1. The front-end connects to server fine the first time, using an explicit `connect()` call.
2. After a specific time, the websocket disconnects — probably due to a timeout elsewhere. (This seems to be 5 min, but can be 30s by using a nginx proxy with timeout settings.)
3. When the frond-end tries to re-connect the first time, the server throws an error without connecting (see log).
4. When the frond-end is forced to re-connect a second time, everything works as expected just like on the first connection.

Here's the error that shows up in the log:

```
19:44:47.834 DEBUG net/identi: error parsing received observed addr for 0xc00023e500 0xc0002c8b10
0xc000138dc0})}] /ip4/127.0.0.1/tcp/4004/ws (QmSDK94dTUDBQoJosR4S5inYycFZHLcfS7FiqnF4snyBZJ) <-> /ip4/127.0.0.1/tcp/57894/ws (QmcqVFhk7eZdeCho8CuBkD6Dtps6NLzfNCekYeAhRiTyPx)>: no protocol with code 478 id.go:363
```

This bug happens reliably whether connecting directly from `js-ipfs` or via `nginx` proxy. From the client-side, this problem happens reliably only with Firefox (surprisingly, Chrome seems fine) but I'd consider this should be fixed in `go-ipfs` on the server side.

* What is protocol code 478?