The #setup() lifecycle callback method is executed at the end of the
TwitterServer#postInjectorStartup@Lifecycle-annotated method
(see: Startup Lifecycle). That is, after the creation
of the Injector but before server warmup has been performed allowing for anything created or started
in this callback to be used in warmup and for instances to be promoted to old gen during object
promotion in the beforePostWarmup lifecycle phase.

Any logic to execute before object promotion and before the server warmup is performed. This is thus
before any external interface has been bound and thus before the server is announced as “healthy”.

Any exception thrown from this method will fail the server startup.

When overriding any lifecycle methods and callbacks, it is important to not perform any blocking
operations as you will prevent the server from properly starting. If there is blocking work that
must be done, it is strongly recommended that you perform this work in a
FuturePool.

Any logic to be run after the server is reported as healthy, bound to an external interface, and
before awaiting on any Awaitables is placed in the #start() method. This is typically starting
long live background processes, starting any processor that should only be started once the
external interface has been successfully bound to port and is accepting traffic, or any other work
that must be completed as part of server startup. See the Awaiting Awaitables section for
more information.

Work to happen after the server is bound to any external port, has performed warmup, object promotion,
and is announced as “healthy”.

Any exception thrown from this method will fail the server startup.

When overriding any lifecycle methods and callbacks, it is important to not perform any blocking
operations in your override as you will prevent the server from properly starting. If there is
blocking work that must be done, it is strongly recommended that you perform this work in a
FuturePool.

If you have long-lived processes which your server starts that you want to ensure exit when the server
exits or trigger the server to exit if the process exits, you should register them as an c.t.util.Awaitable
using the c.t.inject.server.TwitterServer#await callback function.

The purpose of using this callback is to entangle
all the Awaitables within your server such that if any of the Awaitables exit, the entire
server process exits. For example, when starting a regular HTTP or Thrift server, you have two
ListeningServers
in process: the TwitterServer HTTP Admin Interface and the started external server. If you await
(block) on one of the servers and not the other, you can get into a case where the server not being
awaited exits but the process continues to wait on the other server to satisfy the blocking Awaitable
and thus does not exit.

As an example, if you await on just the external interface, the TwitterServer HTTP Admin Interface
may exit because of an error, causing health checking and metrics reporting to fail but your server
process would remain running until killed. Conversely, if you await on just the HTTP Admin Interface
the external server may exit but the admin interface continues to report itself as healthy.

The way to ensure that the exiting of a single Awaitable triggers exiting of any other Awaitable
is to register each Awaitable with the server using the c.t.inject.server.TwitterServer#await
callback function. As the last step of the server startup lifecycle, the server will entangle
all given Awaitables.