fix listener problems

[jbenet]

Our listeners used to hang on accept errors, becuase:

• the listeners were bailing on secure conn fails
• peerstream would hang after 10 temp errors

This PR fixes all that and adds some tests.

thanks so much for finding these @whyrusleeping

[whyrusleeping]

I feel like were throwing errors away here that we may want to at least note somehow... maybe it should also take a func(err error) so we can log those errors if we want?

[btc]

It's a bit inconvenient to do meaningful CR on a PR when most of the new code exists in other repos.

(It's less of an issue when the outside libraries are mature. However, when vendored code is new, we should expect one or two bugs to exist.)

(Would be less of a concern if outside libraries are on a GitHub org with the same ACLs as this repo and we were to get into the practice of doing code reviews on the libraries on an individual basis.)

[jbenet]

It's a bit inconvenient to do meaningful CR on a PR when most of the new code exists in other repos.

Would it help if i linked to the relevant commit diffs?

(Would be less of a concern if outside libraries are on a GitHub org with the same ACLs as this repo)

this is feasible for some things, like peerstream. this is not feasible for everything, i will make tons of small, modular packages that transcend belonging to an org.

I think we see things very differently on when to modularize. to help align our perspectives, here's some stuff that helps express how i approach this:

• http://substack.net/many_things
• https://www.youtube.com/watch?v=DCQNm6yiZh0 (this talk is great -- please watch it -- dotC is a great idea)
• http://substack.net/finding_modules
• JRFC 27 - Hyper Modular Programming System jbenet/random-ideas#27

my thoughts are not the exact same substack's, but we align very well.

We should identify which steps of modularizing things can be automated and which costs can be decreased. I actually timed myself modularizing go-temp-err-catcher:

27min - write it inside go-peerstream/catcher
5min - pull into own repo (readme) (using `hub`)
5min - cleaned up interface to be more user friendly + docs
10min - good tests - i would have not written these. 
            i actually found an error and added a feature
3min - setup travis (`cp ../other/.travis.yml .travis.yml`) 
         - enable it on the browser (may be able to curl this)
1min - forgot license (`cp ../other/LICENSE LICENSE`)
3min - adding godep + make vendor
6min - pulling in new changes
---------
27min - writing it
33min - modularizing

The total cost of modularizing it was a bit more than writing it in the first place, but i found an error while writing tests that probably saved us many hours down the road.

The major costs for me were not actually vendoring, as i expected, but the rote work of godoc + package setup + tests. there may be a script that could automate this dramatically.

usage: go-modularize <path>

extracts package at <path> into its own module:
- runs `{go fmt, golint, go vet}` ensuring you write good code
- creates a git repository at github.com/<username>/go-<packagename>
- adds a README.md file with godoc + travis badge
- adds a LICENSE file (use --license to override default ~/.go-modularize/LICENSE)
- adds a .travis.yml file (skipped with --skip-travis and --skip-tests)
- ensures there are tests. will error + yell at you if there are none (skipped with --skip-tests)
- ships the module, if everything succeeded, uses `hub create` and `git push`

other things tis could do:
- godep vendors modules
- coveralls

On the CR costs, perhaps what can help is:

• include links to relevant commits (the diff is included here, so this is actually no different than doing it locally.
• with godeps, we can do comments in here to other packages, like @whyrusleeping did in my ds-query diff

As mentioned above, a github org will not work for everything and it will not work with other contributors, so we should not rely on it as a pre-requisite for modularity.