ChanServ sets TOPIC twice after a netsplit if TOPICLOCK is enabled

[Essency]

When topiclock is enabled ChanServ sets the topic twice during a sync after a netsplit, the first time when the channel is created (first SJOIN) and the second time when the uplink sends TOPIC with the current topic.

[rfc1459]

There are three issues, actually:

1. services should not issue any TOPIC command until they have fully processed the burst (more on that later);
2. services should reset the channel's topic IFF CS_TOPICLOCK is set and the server sent a topic different than the one stored in ChanServ's database;
3. s2s protocol should be amended to introduce explicit remote EOBs instead of relying on GNOTICE pattern matching (add a new CAPAB to bahamut, perhaps?).

[rfc1459]

As discussed on IRC, the end of a remote burst can be detected by sending a routed PING to the new server and waiting for a PONG to come back.

As for the rest, I'm inclined to suspend all "non-standard" message handling during a burst (so that services adhere strictly to TS5) and save new nicknames and channels onto per-server "burst stacks", which shall be processed right after the end of burst.
This would fix the "double topic" issue and reduce the likelihood of a desynch due to bounced MODE messages.