Return task IDs after emits, deprecate emit_many

Pending_task_ids are never returned after bolt/spout emits, which means
they simply queue up in the ipc _pending_task_ids deque forever.

Aside from the spaghetti code caused by writing direct to stdout,
there’s a more serious bug here.

Since Storm returns the task IDs that a tuple was emitted to after an
emit command as a simple list, emitting multiple tuples to stdout
causes significant difficulty in attempting to tie task IDs to the
prior emits.
Unused instance var.
Fix BatchingBolt race condition and capture errors

ipc.read_tuple which relies on sys.stdin is not thread-safe and in
testing, was shown to exhibit odd behaviour if the main thread tried
reading a tuple while the _batcher thread tried emitting. Remember that
emitting now returns task IDs which could require also reading from
sys.stdin. Having the read_tuple occur only once it has acquired a
batch_lock solves this issue, but raises lock contention.

Also, having self.initialize which calls user code outside of a
try/except wasn’t a good idea so that’s been fixed with a try/except
that wraps all user code during run().
IPC refactor

Bit of a jumbled update here but it was hard to untangle. I’ll explain
the details:

- Setup some useful module-level globals like: topology_name,
component_name, task_id, etc that are mostly used when logging
- Adds support for Python logging using a RotatingFileHanlder which
will log to streamparse.log.path or streamparse.log_path (users can
configure maxBytes and backupCount options passed to
RotatingFileHandler using streamparse.log.max_bytes and
streamparse.log.backup_count
- read_message_lines is killed and now we just use read_message (which
doesn’t try to be a fancy generator)
- Fixed bug in old read_message_lines where we now properly decode to
Unicode assuming input is UTF-8 instead of ASCII
- read_message no longer throws StormIPCExceptions when we start
getting bogus input like EOF or lots of “\n”s from Storm, but instead,
logs warnings as in testing, EOFs were only encountered when Storm was
restarting the worker process
- In ipc_send_message, guard against sending anything but a dict
(command) to Storm, log warning if this is tried
- In ipc.send_message, when sending messages, stdout.flush not called
on Python 3 stdout.buffer
Setup logging in Spout
Setup logging in Bolt and add log messages
Add logging to Spout.run
Better logging in ipc.send_message
Typo
Give BatchingBolt threads friendly names

Helps during debugging, can use threading.current_thread().name.
Override BatchingBolt.emit

BatchingBolt.emit will not return task IDs a tuple was emitted to as it
currently causes a complication due to the _batcher and main thread
calling read_task_ids and read_command respectively.

Properly returning task IDs will require some major reworking of the
IPC layer.

Since we are sure that only the main thread will be reading from stdin
now, we can move tuple reading and group keys outside of the
_batch_lock.
Fix bug in test util ShellProcess.query_subprocess
Formatting
Update Bolt tests to send task_ids after emits

Also, formatting updates.
Update BatchingBolt tests
Add handy instance variables to Bolts and Spouts

Very handy with debugging, perhaps these should actually be “public”
instance vars (e.g. self.debug).
Have read_message exit process on EOF

Reading an EOF from stdin effectively means the parent process (Storm)
is dead and we should just kill ourselves.

Also fixed a few bugs (num_blank_lines instead of blank_lines) and
formatting.
Remove BasicBatchingBolt

BasicBatchingBolt was never in a official release so we don’t need to
support it here.
Python 3 fix for Travis CI
Update default log.max_bytes to 1 MB