Tidy up lifecycle, query, and ingestion logging.

[gianm]

The goal of this patch is to improve the clarity and usefulness of
Druid's logging for cluster operators. For more information, see
https://twitter.com/cowtowncoder/status/1195469299814555648.

Concretely, this patch does the following:

• Changes a lot of INFO logs to DEBUG, and DEBUG to TRACE, with the
  goal of reducing redundancy and improving clarity by avoiding
  showing rarely-useful log messages. This includes most "starting"
  and "stopping" messages, and most messages related to individual
  columns.
• Adds new log4j2 templates that show operators how to enabled DEBUG
  logging for certain important packages. These templates can be found in
  the _common configuration folder in the example clusters under conf/druid.
• Eliminate stack traces for query errors, unless log level is DEBUG
  or more. This is useful because query errors often indicate user
  error rather than system error, but dumping stack trace often gave
  operators the impression that there was a system failure.
• Adds task id to Appenderator, AppenderatorDriver thread names. In
  the default log4j2 configuration, this will put them in log lines
  as well. It's very useful if a user is using the Indexer, where
  multiple tasks run in the same JVM.
• More consistent terminology when it comes to "sequences" (sets of
  segments that are handed-off together by Kafka ingestion) and
  "offsets" (cursors in partitions). These terms had been confused in
  some log messages due to the fact that Kinesis calls offsets
  "sequence numbers".
• Replaces some ugly toString calls with either the JSONification or
  something more operator-accessible (like a URL or segment identifier,
  instead of JSON object representing the same).

[gianm]

The principles I'm trying to follow in this patch are:

• Logs at INFO / WARN / ERROR level should be designed for cluster operators.
• Logs at TRACE / DEBUG level should be designed for Druid developers.
• Less is more. Having too many logs means the useful messages will get lost in a sea of irrelevant messages, because there will be too many to read and operators won't know what to search for.
• Avoid logging "business as usual" things (starting, stopping, initializing, refreshing, found nothing to do, etc).
• Ideally log one message per important lifecycle event (i.e. one log message per segment push to deep storage, one per publish, etc). Not zero and not more than one.

[fjy]

+3000

This is super useful

[lgtm-com]

This pull request introduces 2 alerts when merging b2d3d41 into f139903 - view on LGTM.com

new alerts:

• 2 for Unused format argument

[gianm]

Pushed updates to address some issues found by CI.