We want the default application type to be REACTIVE if webflux is
present (formerly it was NONE). In AWS and Azure we also want
the webflux beans to be switched off in a "lite" application
context (formerly they were unconditional).
Some tests still ignored.
Also adds draft functional bean registration support. The AWS sample
is using that now (it starts up 4x faster in AWS). To activate the
functional beans user has to supply a main class of type
ApplicationContextInitializer.
This can be reverted in 1.1. The compiler relies on being able to
bind itself to @ConfigurationProperties and the APIs changed for that
in Spring Boot 2.0.
Fixes gh-177
If an isolated function doesn't have Message in its classpath, we
will never actually need to instantiate that class. This change
makes sure we check first.
This results in a better experience for users because the consumer
that they write is only applied to a Flux that is subscribed to
by the framework once. It gives better control over the flow of
foos, e.g. if some component wants to subscribe on a thread.
When a Supplier<Flux<Foo>> is composed with a Function<Foo,Bar>
the resulting handler (supplier) should have Flux as its output
wrapper still (the most general output wrapper type in the chain).
A Spring Boot 2.0 app should behave the same as a Spering Boot 1.5
app with this change. The key thing was to change the return type
of the FunctionController and move the computation of single
valuedness for the output there (instead of trying to do it in the
return value handler, which isn't used in Spring 5).
