writer: refactoring to support async functionality
nsq_to_nsq: proxy a topic from producer(s) to destination nsqd over TCP
Merge pull request #255 from mreiferson/async_writer_255

writer: support "async" publishing / nsq_to_nsq
update ChangeLog
fix 32bit alignment issues for 64bit atomic variables
Merge pull request #244 from mreiferson/alignment_244

nsq: 386 arch support
update travis builds to go1.1.2 and add GOARCH=386
nsqadmin: add node information
Merge pull request #260 from mreiferson/notification_260

nsqadmin: notification for tombstone_topic_producer missing node data
bump 0.2.22; go-nsq 0.3.2; update ChangeLog
move examples to apps & bench
Merge pull request #262 from mreiferson/apps_262

rename examples dir
go-nsq: move to github.com/bitly/go-nsq
Merge pull request #264 from mreiferson/move_go_nsq_264

go-nsq: move to github.com/bitly/go-nsq
nsqd: increase default output buffer timeout:

This change significantly impacts CPU usage on an `nsqd`
with many clients by greatly reducing the amount of work
the Go runtime has to do to maintain its internal heap
of timers.

Previously, the default was `5ms` which meant that 200 times
per second a timer event would fire (and consequently sift
the heap).

If you multiply that by a large # of clients, say 500, you
can quickly see why this would be significant.

    200 x 500 = 100,000 heap sifts per second

Obviously, it's not just the *number* of timers but their
*resolution* that's important.

The other interesting point is that despite the `V2` protocol
`messagePump` *ignoring* the timer when it looped after a previous
flush, the Go runtime still needs to maintain the timer and attempt
to write to the timer's output channel... costing precious cycles
and context switches.

By increasing the default resolution of the timer,
we significantly reduce the work the Go runtime needs to do.

In testing this reduced CPU usage on an *idle* nsqd from 33% to 3%
with 250 clients.

What does this impact?

The client output buffer timeout actually does two things...

 1. It determines the amount of time a client will accumulate
    data in its output buffer before flushing and writing to
    the socket.

 2. It bounds the maximum amount of time a client with
    `max_in_flight > 1` will wait for additional messages
    before flushing.

The second case is the interesting one.  To elaborate, the
pathological case is that for a client subscribed to a
*low-volume* topic, with a `max_in_flight > 1`, messages
can be delivered with up to `output_buffer_timeout` latency.

The `max_in_flight > 1` is important, because `messagePump`
automatically flushes when a client is in a state where it
is not ready to receive messages (i.e. `RDY = 0`).

This means that for clients that absolutely *need* to have
`max_in_flight > 1` on *low-volume* topics *and* prioritize
latency, they should disable output buffering, which we already
support via `IDENTIFY`.
Merge pull request #236 from mreiferson/high_cpu_236

nsqd: high CPU when idle w/ lots (thousands) of topics/consumers
bump to 0.2.23-alpha
nsqd: add deflate compression negotiation:

* add --deflate and --max-deflate-level flag
* add feature negotiation for nsqd clients
nsqd: add framed snappy compression
nsqd: add/use DefaultBufferSize