Use a separate mock server for benchmarks

[jchambers]

This has two good outcomes:

1. Because we've removed a lot of logic, it's less likely that we'll be inadvertently benchmarking the server instead of the client.
2. We don't have to worry about performance as much for the mock server we use for testing; this frees us to write code that is clearer and simpler (and ideally more likely to be correct), but maybe a little slower.

[jchambers]

Would anybody like this benchmark server to live in the main pushy module (as opposed to the benchmark module)? I'm inclined to leave it out to keep the number of public classes small, but could certainly be persuaded otherwise if "send notifications to a thing that always says yes" is a common use case in integration testing.

[n8leon]

👍 :-)
Yup, will certainly be helpful for us to have a sink in order to load test our own code.
Thx!

[jchambers]

To really make this public in a non-crazy way, I think we need to abstract out some of the existing mock server stuff and refactor some things. For now, I'm going to merge this as-is to clear the way for #451, but with the understanding that we'll revisit the public benchmark server thing once that's under control.

I've filed #459 so we don't lose track of the idea.

[jchambers]

I'm not sure what's going wrong with test status reporting; the build certainly passed, so I'm going to merge this and figure out what's up with Travis as a separate effort.