Use sbt 0.13.6
Use latest sbt wrapper script
Use ScalaTest 2.2.1
Disable ZK retries in Kafka spout for our Kafka/Storm test topology

Background
==========

If you run many test topologies then you may at some point run into (many) log errors similar to:

    2014-09-16 13:44:27 o.a.c.ConnectionState [ERROR] Connection timed out for connection string (127.0.0.1:2181) and timeout (15000) / elapsed (15219)
    org.apache.curator.CuratorConnectionLossException: KeeperErrorCode = ConnectionLoss
      at org.apache.curator.ConnectionState.checkTimeouts(ConnectionState.java:198) [curator-client-2.5.0.jar:na]
      at org.apache.curator.ConnectionState.getZooKeeper(ConnectionState.java:88) [curator-client-2.5.0.jar:na]
      at org.apache.curator.CuratorZookeeperClient.getZooKeeper(CuratorZookeeperClient.java:115) [curator-client-2.5.0.jar:na]
      at org.apache.curator.framework.imps.CuratorFrameworkImpl.performBackgroundOperation(CuratorFrameworkImpl.java:807) [curator-framework-2.5.0.jar:na]
      at org.apache.curator.framework.imps.CuratorFrameworkImpl.backgroundOperationsLoop(CuratorFrameworkImpl.java:793) [curator-framework-2.5.0.jar:na]
      at org.apache.curator.framework.imps.CuratorFrameworkImpl.access$400(CuratorFrameworkImpl.java:57) [curator-framework-2.5.0.jar:na]
      at org.apache.curator.framework.imps.CuratorFrameworkImpl$4.call(CuratorFrameworkImpl.java:275) [curator-framework-2.5.0.jar:na]
      at java.util.concurrent.FutureTask.run(FutureTask.java:262) [na:1.7.0_55]
      at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [na:1.7.0_55]
      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [na:1.7.0_55]
      at java.lang.Thread.run(Thread.java:745) [na:1.7.0_55]

These log errors are followed by:

    2014-09-16 13:44:32 o.a.c.f.i.CuratorFrameworkImpl [ERROR] Background operation retry gave up
    org.apache.zookeeper.KeeperException$ConnectionLossException: KeeperErrorCode = ConnectionLoss
      at org.apache.zookeeper.KeeperException.create(KeeperException.java:99) ~[zookeeper-3.4.5.jar:3.4.5-1392090]
      at org.apache.curator.framework.imps.CuratorFrameworkImpl.checkBackgroundRetry(CuratorFrameworkImpl.java:710) [curator-framework-2.5.0.jar:na]
      at org.apache.curator.framework.imps.CuratorFrameworkImpl.performBackgroundOperation(CuratorFrameworkImpl.java:827) [curator-framework-2.5.0.jar:na]
      at org.apache.curator.framework.imps.CuratorFrameworkImpl.backgroundOperationsLoop(CuratorFrameworkImpl.java:793) [curator-framework-2.5.0.jar:na]
      at org.apache.curator.framework.imps.CuratorFrameworkImpl.access$400(CuratorFrameworkImpl.java:57) [curator-framework-2.5.0.jar:na]
      at org.apache.curator.framework.imps.CuratorFrameworkImpl$4.call(CuratorFrameworkImpl.java:275) [curator-framework-2.5.0.jar:na]
      at java.util.concurrent.FutureTask.run(FutureTask.java:262) [na:1.7.0_55]
      at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [na:1.7.0_55]
      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [na:1.7.0_55]
      at java.lang.Thread.run(Thread.java:745) [na:1.7.0_55]

These log messages are -- directly or indirectly -- caused by Storm's Kafka spout, which has a hardcoded ZK connection
timeout of 15000 ms (cf. external/storm-kafka/src/jvm/storm/kafka/DynamicBrokersReader.java).  By default the spout will
attempt to reconnect to ZK on a connection loss up to 5 retries and with a retry interval of 1000 ms (cf. the
settings storm.zookeeper.retry.times and storm.zookeeper.retry.interval in Storm's defaults.yaml).  Here, the spout
relies on Apache Curator to handle any ZK-related communication, which is the reason the stacktraces above point to
Curator classes.

This commit disables these retry attempts by setting the number of retries to 0 (zero).

Root cause still unknown
========================

What is still unclear is why the spout/Curator is even able to perform such reconnection attempts (which will then
lead to the log messages above), because we expect Storm's testing API to fully shutdown a topology (and in our case
this would include the Kafka spout), and we observed that the messages above are logged AFTER this topology shutdown
has already happened.

One possibility is that these reconnect attempts are caused by Apache Curator, which is used by storm-kafka to
manage the ZK-related communication.  What may happen is that Storm's Testing API does correctly shutdown the
LocalCluster's, but a separate, Curator-related thread is still running in the background and attempting to reconnect
to the stopped embedded ZK instance.

Another possibility is a bug in Storm's testing API:  Maybe it is not correctly shutting down embedded
LocalCluster's, so what may happen is that lingering processes (here: topology/spout) are still running in the
background and, in our case of the Kafka spout, trying to reconnect to a stopped embedded ZK instance.
Consolidate logging to use our own Logging traits (based on logback)
Add port details to log messages of embedded Kafka and ZooKeeper
Squelch error messages logged by org.apache.curator.framework.imps.CuratorFrameworkImpl

These messages are logged (directly or indirectly) because of ZK timeouts
in storm-kafka, i.e. Storm's built-in KafkaSpout we are using to read
Kafka data into our Storm topologies.  It is unclear whether we can
prevent those messages in the first place as we are not certain what
causes them.

This commit is a follow-up on commit b4a9bc0, which disables ZK retries
for our Kafka/Storm test topology.
Further explain ScalaTest output settings, and how they can be helpful when debugging
Update CHANGELOG
Exclude com.101tec:zkclient from Kafka dependency so we can enforce version 0.4
Squelch error output of AvroDecoderBolt in tests
Add link to Storm basic training
Squelch error output of AvroKafkaSinkBolt in tests
Update example test output