I removed the unecessary plugins from the build and reworked it to use
the ci friendly way of setting the version for releases (see
https://maven.apache.org/maven-ci-friendly.html).

This removes the spring-boot-starter-parent from the build, and
duplicates the necessary plugin configuration in he Spring Boot Admin'
parent instead. This way our BOM doesn't include version for
dependencies managed by boot's BOM

The info should be updated when the registration has changed. In order
to prevent a stale instance info, the sba client includes a "startup"
timestamp in the metadata as default. So when the instance is restarted
the registration changes and the info is updated, even when the instance
isn't considered as down in between.

To prevent this when using a discovery client you need to add a value
to the metadata which changes with every restart.
(e.g. `random=${random.value}`)

fixes #556

fixes #590 (new client - old server)

fixes #578

It turns out that imho when talking about application groups (identified
by name) and application instances it's just logical to speak of
instances and applications. So the Application class get's renamed to
Instance. So an Application is now a set of Instances with the same name

fixes #515.

The Spring team discourages the use of the `spring.*` configuration
namespace, hence I use the major update and move all properties. With
this commit all client related properties are moved to `sbadmin.client`.

In order to reduce the noise in the application log, only the first
failure when registering is logged on the WARN level. All further
attempts are logged using the DEBUG level.

closes #490

With this commit two new properties were added to ease the client
configuration when used in servlet containers:
`spring.boot.admin.client.management-base-url` and
`spring.boot.admin.client.service-base-url`. Both properties can be used
to specify protocol, host and port for the urls. The paths will still be
guessed and appended to the base-urls. Additionally the servlet context
path is not read from the properties but from the ServletContext itself.

closes #488

closes #404

With this commit you can now associate your applications with custom
metadata using `spring.boot.admin.client.metadata.*` sensitive values
are recognized by key and are masked in the http interface.

This can be useful in the future if there are instance specific settings
which should be used by the admin server, e.g. custom notification
recipients.

For now there is no extra imetadata view in the ui. The values are shown
in the environment view.

With this commit the concept of an ApplicationFactory is introduced.
This allows you to easily modify the information used to register
your application at the admin server

closes #331

The managment.ssl.* properties needs to be taken into account when they
are explicitly set and the managment.port differs from server.port

fixes #333

With this commits the server no longer depends on the client. The
classes for the clients are moved to de.codecentric.boot.admin.client
package.
Since the perspective on applications is totally different from client
and server the model has been split apart.

What means this for users:
1) The client is no longer a transitive dependency for your admin server
you may need to add it explicitly to your dependencies, respectively
jolokia-core in case you're using discovery and want to use the jmx-bean
interface

2)In case you have cutomised parts of the client you need to reflect the
package change.

fixes #332

Since the actuator mvc endpoint beans live in a child context when the
server and management port aren't the same, the admin client shouldn't
depend on those beans.

fixes #302

If server.address or management.adress is set use it's value to resolve the
hostname used for management-/service-url.

With the fix for #260 we ignored all events from child contexts which turns out
to be wrong since the "main" application context is, in case spring cloud config
is used, is a child  of the bootstrap context. So we just act on the events from
WebApplicationContexts. After they're fired up the needed port information is
available.

fixes #277

When includeing spring-cloud-netflix-hystrix-amqp to your application it looks
like that the ApplicationReadyEvent is fired twice (from main and child
application context). So we need to take care that only the events from the
main applications are taken into account.

fixes #260

As it turns out (rather obvious) that the ThreadPools for registration and
status updating needs to be destroyed on application shutdown so that the
worker threads gets cancelled. To achieve this we simply register the
ThreadPools as spring beans (since they are implementing DisposableBean).

fixes #253

Apparently when the Netty4ClientHttpRequestFactory is being used the content-
lenght header is not being set in the POST request. Therefore the simple one is
now being hardcoded to override decetion by the RestTemplateBuilder.

fixes #248

Fix the usage of RestTemplateBuilders which wasn't covered by PR #247

The RestTamplateBuilder doesn't save the arguments, it returns a new Builder instance, with the saved arguments. So you have to save the builder everytime you call a function on it.

With this commit you can from now on register the application on multiple
servers. You need to set spring.boot.admin.register-once to false and
assign a list of urls to spring.boot.admin.url