ds-dev reloading page causes problems due to Twine

[teleclimber]

This is a more general problem than what is tracked in #9. It primarily has to do with the way we designed the Twine Service interface in Dropserver Go code.

type TwineService interface {
    Start(UserID, *twine.Twine)
    HandleMessage(twine.ReceivedMessageI)
}

The big problem is that when Twine quits, you want to unsubscribe from the various event systems you hooked into. But twine.ReceivedMessageI doesn't give you access to underlying Twine, nor tells you when it needs to stop. (It should).

I think Start should return an interface that has HandleMessage as a function. That way the handler can have access to the Twine object. Also as a general rule, each instance of Twine should get its own service object.

[teleclimber]

This is fixed thanks to new TwineService2 interface:

// TwineService2 returns a TwineServiceI on start
type TwineService2 interface {
    Start(UserID, *twine.Twine) TwineServiceI
}

// TwineServiceI handles incoming messages for a twine connection
type TwineServiceI interface {
    HandleMessage(twine.ReceivedMessageI)
}

Thanks to this I was able to retool services such that they close down more completely. See abe0411c530bd928f3ccb3acb2602ea9ec044b08 and 71d0cd6a2cc0db03c5b9c0e367e0cd451ae23186.

Note that the problem with Twine not closing ref request channels is still there, and that leaves goroutines hanging, but it does not affect the function of the rest of the program, as best I can tell.