disconnect client if it submits an already accepted changeset based on a...

...n old revision

a changeset that is based on an old revision and contains the same changes that have produced baseRev+1 will satisfy the Changeset.follow checks and a new revision is pushed to all clients, but won't contain any real changes (e.g. if a cs that deletes all default text is submitted twice with baseRev:0, "Z:6c<6b|5-6b$", a new revision 2 that contains "Z:1>0$" will be pushed).
there is no limit how old a baseRev can be compared to the current head revision - which is good, because there cannot be a good approximation for this, as it depends on the number of clients, the size of the pad etc.
but it is bad in the described case as it can be used to insert an endless amount of revisions and the consequence are endless db round trips.

I left a "TODO" notice in the patch, because as I understand it, the client should stop sending changesets, receive all revisions and update its view of the pad to the latest head, and check if the changeset is still okay and resubmit it. but I couldn't find code that somehow does this, so I don't know what really happens, in case the client has missed some NEW_CHANGES.