See gh-23999

Before this change an @MessageMapping could be matched to any RSocket
interaction type, which is arguably too flexible, makes it difficult to
reason what would happen in case of a significant mismatch of
cardinality, e.g. request for Fire-And-Forget (1-to-0) mapped to a
method that returns Flux, and could result in payloads being ignored,
or not seen unintentionally.

This commit checks @ConnectMapping method on startup and rejects them
if they return any values (sync or async). It also refines each
@MessageMapping to match only the RSocket interaction type it fits
based on the input and output cardinality of the handler method.
Subsequently if a request is not matched, we'll do a second search to
identify partial matches (by route only) and raise a helpful error that
explains which interaction type is actually supported.

The reference docs has been updated to explain the options.

Closes gh-23999

Take a slice of the metadata if not using composite metadata to allow
reading it multiple times. For composite metadata this is not an isuse
as it is ensured by the underlying RSocket Java API.

This commit renames the `metadataExtractors` method to something that is
closer to the actual intent: addming new metadata extractors against the
registry given as a parameter of the `Consumer`.

The method is renamed to `metadataExtractorRegistry`.

See gh-23649

This commit makes it possible to send requests without
requiring to call data(Mono.empty()). It introduces a
dedicated MetadataSpec interface and merge ResponseSpec
into RequestSpec for more flexibility.

Closes gh-23649

Prior to this commit, customizing the extraction of RSocket metadata
from frames would require developers to override the default
`MetadataExtractor` while configuring `RSocketStrategies`.
This touches on many infrastructure parts, whereas the goal is just to
configure an extra metadata entry extractor using already configured
codecs.

This commit adds a way to register metadata entry extractors on the
`RSocketStrategies` builder with a `Consumer`-based API.

Closes gh-23645

Closes gh-23513

This allows encoding of metadata values externally via some
existing API for encoding RSocket metadata, rather than relying on
registered Encoders.

Also remove explicit checks for DataBuffer since those are supported
through the DataBufferEncoder (registered by default).

See gh-23513

Closes gh-23137

For public use, these constants aren't ideally exposed through an SPI
like MetadataExtractor, and there isn't any other obvious place either.
In practice the only public API where these can be passed in is
RSocketRequester and RSocketMessageHandler both of which already
default to composite metadata anyway, leaving only the routing MimeType
to be used potentially but much less likely.
Due to existence of similar constants in the RSocket itself, i.e.
WellKnownMimeType, we can get by internally too without declaring
MimeType constants from a central place.

take advantage of the symmetrical SocketAcceptor methods now available
on RSocketFactory for both client and server side.

Expecting data first and metadata second aligns better with the single
arg variant that accepts data. This is also consistent with the
RSocket API in the create methods of ByteBufPayload and DefaultPayload.

Closes gh-23368

To be re-used also for creating metadata for the setup payload.

See: gh-23368

Use rsocketStrategies field with mutate() to ensure consistency
with internal state.

Remove transparent initialization of decoders in MetadataExtractor
and expect them to be set to avoid unintended side effects.

Remove RSocketStrategies argument from the contract to avoid having to
pass them every time especially by application components, like an
implementation of a Spring Security matcher.

Decouple DefaultMetadataExtractor from RSocketStrategies in favor of
a decoders property and an internal DataBufferFactory, which does not
need to be the shared one as we're only wrapping ByteBufs.

If there is more than one non-basic codec (e.g. CBOR and JSON)
RSocketRequester.Builder takes the mime type of the first one rather
than giving up. It is a valid scenario (JSON for server responding to
browser, and CBOR for client talking to server) and it is the default
situation in Boot, and after all the point here is to pick some default
as best as we can with the worst possible outcome being a server
refusing the connection if it doesn't support the mime type. Beyond
that applications can set the dataMimeType on the builder explicitly.

To match that change this commit also ensures RSocketMessageHandler
rejects proactively data mime types it does not support at the point
of accepting a connection.

This commit ensures getRSocketStrategies() now reflects the state of
corresponding RSocketMessageHandler properties even if those change
after a call to setRSocketStrategies.

RSocketMessageHandler has default Encoder/Decoder initializations
consistent with the recent changes to RSocketStrategies.

Now that responder RSocketStrategies also exposes responder strategies,
AnnotationClientResponderConfigurer is reduced and no longer needs to
be public. This commit folds it into RSocketMessageHandler as a nested
class and exposes it as a ClientRSocketFactoryConfigurer through a
static method that accepts the handlers to use.

Effectively a shortcut for creating RSocketMessageHandler, giving it
RSocketStrategies, calling afterPropertiesSet, and then the instance
createResponder.

See gh-23314

Now that RSocketStrategies has default settings it makes sense to have
a create() shortcut vs builder().build().

This commit also updates tests to take advantage of improvements in this
and the previous two commits.

See gh-23314

RouteMatcher and MetadataExtractor can now be configured on and
accessed through RSocketStrategies. This simplifies configuration for
client and server responders.

See gh-23314

1. RSocketStrategies hooks in the basic codecs from spring-core by
default. Now that we have support for composite metadata, it makes
sense to have multiple codecs available.

2. RSocketStrategies is pre-configured with NettyDataBufferFactory.

3. DefaultRSocketRequesterBuilder configures RSocket with a frame
decoder that matches the DataBufferFactory choice, i.e. ensuring
consistency of zero copy vs default (copy) choice.

4. DefaultRSocketRequesterBuilder now tries to find a single non-basic
decoder to select a default data MimeType (e.g. CBOR), or otherwise
fall back on the first default decoder (e.g. String).

See gh-23314

Closes gh-23310

The new interface supersedes ClientResponderFactory and is more general,
for any RSocketFactory customization.

DefaultClientResponderFactory implements the new interface and is
renamed to AnnotationClientResponderConfigurer.

See gh-23170

Simplify the creation of MetadataExtractor by not requiring
RSocketStrategies up front. The strategies are already configured in higher
level places like RSocketMessageHandler that invoke the MetadataExtractor.
The strategies are now passed in as an argument to the extract method.

The move up the hierarchy reflects the fact that MetadataExtractor
is more generally useful and not tied to annotations.

Prior to this commit, the `RSocketRequester.Builder` would allow to
configure directly annotated handlers for processing server requests.
This lead to a package tangle where the `o.s.messaging.rsocket` would
use classes from `o.s.messaging.rsocket.annotation.support` package.

This commit introduces the `ClientResponderFactory` interface for
configuring a responder on the client RSocket factory. Its goal is
to be compatible with future changes with a functional variant for
RSocket handlers.

Closes gh-23170

Closes gh-23292

See gh-23170