If the appender does not have a thread pool configuration, we now use
the context's ExecutorService instead of creating a new one based on the
default ThreadPoolConfiguration.

When testing the exception reported by SocketConnectorBase after a
connection failure, the test now uses lock and associated condition to
avoid synchronization issues.

The context injected by logback into SocketServer is subsequently
injected into RemoteAppenderServerRunner.  The runner simply casts it to
LoggerContext before injecting it into the client object.

updated documentation for simplified scala-less build, increased timeout in AppenderAttachableImplLockTest

work in progress on documentation of SocketRemote/ServerSocketAppender

Committing before moving to a clone of qos-ch/logback instead of
my fork.

removed some assertions that were not critical

The test was system timing sensitive due to testing some assertions on
fields without proper synchronization.  The assertions themselves were
not especially critical, and adding the synchronization would have added
significant complexity, so the assertions were removed.

reduce system timing sensitivity in SocketConnectorBaseTest

LOGBACK-826: work in progress on documentation

Now using a larger delay tolerance and additional Thread.join calls to
give the connector thread time to exit before testing assertions that
it did exit properly.

Other example configurations using layout remain and need the same
treatment.

changed SocketRemote address property to host

SocketAppenderBase uses 'remoteHost'.  The 'remote' suffix seems a
little redundant when configuring the property inside of a <remote>
component, so the preferred name is 'host' in SocketRemote.  However,
for consistency with SocketAppenderBase, this property can also be set
using 'remoteHost'.

removed name property from SocketRemote

The name served no real purpose, while creating potential for confusion
and additional noise in the configuration.

LOGBACK-826: added SocketRemote examples

Simple examples of configuring a ServerSocketAppender and a
corresponding SocketRemote.

Improvements to error logging in ConcurrentServerRunner

Leftover from the removal of the logging methods.

ConcurrentServerRunner was delegating logging to methods defined by a
subclass.  For subclasses defined in core, these methods were simply
delegating to methods of ContextAware.  For subclasses defined elsewhere
(in which a LoggerContext might be available) logging might be handled
differently.

The logging produced by ConcurrentServerRunner is mostly intended to be
diagnostic, so for consistency (no matter which module might contain the
subclass) logging is now handled exclusively through ContextAware.  This
implies that this diagnostic logging is available only when the
LoggerContext is configured for debugging, but at least that limitation
is now consistent across subclasses of ConcurrentServerRunner.

Handle RejectedExecutionException in ConcurrentServerRunner

When the Executor rejects an execute request for a client runner,
we summarily close the client socket to avoid a temporary resource
leak.

Cleaning up finally clauses with nested try blocks

LOGBACK-625: create new component that acts as a client for ServerSocketAppender

Needed some missing classes from logback master.

Not sure if the original author prefers the wildcard import...

SSLSocketRemote has an 'ssl' property of type SSLConfiguration.