Allow customizing socket timeouts.

Previously, if you try to consume a message with a timeout greater than 10 seconds,
but you don't receive data in those 10 seconds, a socket.timeout exception is raised.
This allows a higher socket timeout to be set, or even None for no timeout.
Read the correct number of bytes from kafka.

According to the protocol documentation, the 4 byte integer at the beginning
of a response represents the size of the payload only, not including those bytes.
See http://goo.gl/rg5uom
* Guarantee reading the expected number of bytes from the socket every time
* Remove bufsize from client and conn, since they're not actually enforced

Notes:

This commit changes behavior a bit by raising a BufferUnderflowError when
no data is received for the message size rather than a ConnectionError.

Since bufsize in the socket is not actually enforced, but it is used by the consumer
when creating requests, moving it there until a better solution is implemented.
Allow None timeout in FetchContext even if block is False
Reset consumer fields to original values rather than defaults in FetchContext
SimpleConsumer flow changes:
* Combine partition fetch requests into a single request
* Put the messages received in a queue and update offsets
* Grab as many messages from the queue as requested
* When the queue is empty, request more
* timeout param for get_messages() is the actual timeout for getting those messages
* Based on https://github.com/mumrah/kafka-python/pull/74 -
  don't increase min_bytes if the consumer fetch buffer size is too small.

Notes:

Change MultiProcessConsumer and _mp_consume() accordingly.

Previously, when querying each partition separately, it was possible to
block waiting for messages on partition 0 even if there are new ones in partition 1.
These changes allow us to block while waiting for messages on all partitions,
and reduce total number of kafka requests.

Use Queue.Queue for single proc Queue instead of already imported
multiprocessing.Queue because the latter doesn't seem to guarantee immediate
availability of items after a put:

>>> from multiprocessing import Queue
>>> q = Queue()
>>> q.put(1); q.get_nowait()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/multiprocessing/queues.py", line 152, in get_nowait
    return self.get(False)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/multiprocessing/queues.py", line 134, in get
    raise Empty
Queue.Empty
Remove SimpleConsumer queue size limit since it can cause the iterator
to block forever if it's reached.
Add buffer_size param description to docstring
Add iter_timeout option to SimpleConsumer. If not None, it causes the iterator to exit when reached.
Also put constant timeout values in pre-defined constants
Add comments and maintain 80 character line limit
Add and fix comments to protocol.py
Add note about questionable error handling while decoding messages.
Will remove once any error handling issues are resolved.
Fix unit tests.

This is pretty much a rewrite. The tests that involve offset requests/responses
are not implemented since that API is not supported in kafka 0.8 yet.
Only kafka.codec and kafka.protocol are currently tested, so there is more work to be done here.
Style fix for imports
Fix seek offset deltas

We always store the offset of the next available message, so we shouldn't decrement the offset deltas
when seeking by an extra 1
Raise a ConnectionError when a socket.error is raised when receiving data
Also, log.exception() is unhelpfully noisy. Use log.error() with some error details in the message instead.
Fix client error handling

This differentiates between errors that occur when sending the request
and receiving the response, and adds BufferUnderflowError handling.
Add a limit to fetch buffer size, and actually retry requests when fetch size is too small

Note: This can cause fetching a message to exceed a given timeout, but timeouts are not guaranteed anyways, and in this case it's the client's fault for not sending a big enough buffer size rather than the kafka server. This can be bad if max_fetch_size is None (no limit) and there is some message in Kafka that is crazy huge, but that is why we should have some max_fetch_size.
Handle starting/stopping Kafka brokers that are already started/stopped in integration tests

If some of the tests stop brokers then error out, the teardown method will try to close the
same brokers and fail. This change allows it to continue.
Remove unnecessary brackets