add listener-endpoint plugins

[Brian Warner]

As discussed in ​https://tahoe-lafs.org/trac/tahoe-lafs/ticket/517#comment:54 , it will help Tahoe if we can add a server-side plugin mechanism to Foolscap.

Once #203 is done, tub.listenOn() will be able to accept arbitrary server-endpoint descriptor strings: anything that Twisted's endpoints.serverFromString() can handle. This plugin will layer in front of that, so calling tub.addServerPlugin("foo", plugin) will make a subsequent tub.listenOn("foo:stuff") call get its endpoint from plugin.get_endpoint("foo:stuff") instead of endpoints.serverFromString("foo:stuff").

If no plugin is registered for the given type, it will always fall back to endpoints.serverFromString(). This is different from clients, where unrecognized connection hints are ignored. The security properties for server descriptors are different (they come from the local admin, not the remote FURL provider), so we don't need to prohibit any particular types.

This gives the plugin the opportunity to include additional configuration options when constructing the endpoint. Twisted has a built-in plugin mechanism for installing endpoint-string parsers, but it is global: any extra information (like which Tor daemon to use when allocation a .onion address) would have to be provided in the descriptor string itself. For Tahoe, that's a nuisance, because we must already provide this data elsewhere for client purposes. Without plugins at the Foolscap layer, the Tahoe config would need to duplicate this data in both the client section and the tub.port string.

[Brian Warner]

the logging fixes (#244) take priority, pushing this out a release

[Brian Warner]

Milestone renamed

[Brian Warner]

As discussed in 55:ticket:203, I'd rather pass real Endpoints into Tub.listenOn(), rather than strings that need parsing. This removes the need for a listener-endpoint-descriptor-parser plugin.

Or, rather, it forces the calling application to make this decision. In the case of Tahoe, I think we'll statically decide what tub.port should be at node-creation time (e.g. for Tor it's going to be tcp:port=xyz:interface=127.0.0.1 and will be associated with some onion-service construction that's Tahoe's responsibility too).

I think that will be pretty straightforward for normal listeners, where things stay put once the node is constructed. Do we have any use cases that need something more dynamic? Like, something where each time we start up, we have to build a new onion address?

So for now, I'm going to WONTFIX this, and aim for tub.listenOn(ep) instead.