Fix broken cross reference links

Resolves #3018

docs/modules/ROOT/pages/spring-cloud-stream/bindings.adoc

@@ -5,7 +5,7 @@
 As stated earlier, _Bindings_ provide a bridge between the external messaging system (e.g., queue, topic etc.) and application-provided _Producers_ and _Consumers_.
 
 The following example shows a fully configured and functioning Spring Cloud Stream application that receives the payload of the message
-as a `String` type (see <<Content Type Negotiation>> section), logs it to the console and sends it down stream after converting it to upper case.
+as a `String` type (see xref:spring-cloud-stream/content-type.adoc#content_type_management[Content Type Negotiation] section), logs it to the console and sends it down stream after converting it to upper case.
 
 [source, java]
 ----

docs/modules/ROOT/pages/spring-cloud-stream/content-type.adoc

@@ -1,4 +1,4 @@
-[[content-type-management]]
+[[content_type_management]]
 = Content Type Negotiation
 
 Data transformation is one of the core features of any message-driven microservice architecture. Given that, in Spring Cloud Stream, such data

docs/modules/ROOT/pages/spring-cloud-stream/functional-binding-names.adoc

@@ -26,7 +26,7 @@ The naming convention used to name input and output bindings is as follows:
 
 The `in` and `out` corresponds to the type of binding (such as _input_ or _output_).
 The `index` is the index of the input or output binding. It is always 0 for typical single input/output function,
-so it's only relevant for <<Functions with multiple input and output arguments>>.
+so it's only relevant for xref:spring-cloud-stream/producing-and-consuming-messages.adoc#functions_with_multiple_input_and_output_arguments[Functions with multiple input and output arguments].
 
 So if for example you would want to map the input of this function to a remote
 destination (e.g., topic, queue etc) called "my-topic" you would do so with the following property:
@@ -54,9 +54,9 @@ properties can refer to `input` binding name instead (e.g.,  `--spring.cloud.str
 NOTE: While descriptive binding names may enhance the readability aspect of the configuration, they also create
 another level of misdirection by mapping an implicit binding name to an explicit binding name. And since all subsequent
 configuration properties will use the explicit binding name you must always refer to this 'bindings' property to
-correlate which function it actually corresponds to. We believe that for most cases (with the exception of <<Functional Composition>>)
+correlate which function it actually corresponds to. We believe that for most cases (with the exception of xref:spring-cloud-stream/producing-and-consuming-messages.adoc#functional-composition[Functional Composition])
 it may be an overkill, so, it is our recommendation to avoid using it altogether, especially
 since not using it provides a clear path between binder destination and binding name, such as `spring.cloud.stream.bindings.uppercase-in-0.destination=sample-topic`,
 where you are clearly correlating the input of `uppercase` function to `sample-topic` destination.
 
-For more on properties and other configuration options please see <<Configuration Options>> section.
+For more on properties and other configuration options please see xref:spring-cloud-stream/configuration-options.adoc#configuration-options[Configuration Options] section.

docs/modules/ROOT/pages/spring-cloud-stream/producing-and-consuming-messages.adoc

@@ -48,7 +48,7 @@ public class MyFunctionBootApp {
 In the preceding example, we define a bean of type `java.util.function.Function` called _toUpperCase_ to be acting as message handler
 whose 'input' and 'output' must be bound to the external destinations exposed by the provided destination binder.
 By default the 'input' and 'output' binding names will be `toUpperCase-in-0` and `toUpperCase-out-0`.
-Please see <<Functional binding names>> section for details on naming convention used to establish binding names.
+Please see xref:spring-cloud-stream/functional-binding-names.adoc#functional-binding-names[Functional Binding Names] section for details on naming convention used to establish binding names.
 
 Below are the examples of simple functional applications to support other semantics:
 
@@ -315,7 +315,7 @@ When using Observability support provided by the framework as well as supporting
 ==== StreamBridge and Dynamic Destinations
 
 `StreamBridge` can also be used for cases when output destination(s) are not known ahead of time similar to the use cases
-described in <<Routing FROM Consumer>> section.
+described in xref:spring-cloud-stream/event-routing.adoc#routing-from-consumer[Routing FROM consumer] section.
 
 Let's look at the example
 
@@ -344,7 +344,7 @@ public class WebSourceApplication {
 As you can see the preceding example is very similar to the previous one with the exception of explicit binding instruction provided via
 `spring.cloud.stream.output-bindings` property (which is not provided).
 Here we're sending data to `myDestination` name which does not exist as a binding. Therefore such name will be treated as dynamic destination
-as described in <<Routing FROM Consumer>> section.
+as described in xref:spring-cloud-stream/event-routing.adoc#routing-from-consumer[Routing FROM consumer] section.
 
 
 In the preceding example, we are using `ApplicationRunner` as a _foreign source_ to feed the stream.
@@ -399,7 +399,7 @@ Or if you send data as a `Message`, its content type will be honored.
 
 Spring Cloud Stream supports multiple binder scenarios. For example you may be receiving data from Kafka and sending it to RabbitMQ.
 
-For more information on multiple binders scenarios, please see <<Binders>> section and specifically <<Multiple Binders on the Classpath>>
+For more information on multiple binders scenarios, please see xref:spring-cloud-stream/binders.adoc#binders[Binders] section and specifically xref:spring-cloud-stream/multiple-binders.adoc#multiple-binders[Multiple Binders on the Classpath]
 
 In the event you are planning to use StreamBridge and have more then one binder configured in your application you must also tell StreamBridge 
 which binder to use. And for that there are two more variations of `send` method:
@@ -546,7 +546,7 @@ the fact that you can compose _reactive_ and _imperative_ functions.
 
 The result of a composition is a single function which, as you may guess, could have a very long and rather cryptic name (e.g., `foo|bar|baz|xyz. . .`)
 presenting a great deal of inconvenience when it comes to other configuration properties. This is where _descriptive binding names_
-feature described in <<Functional binding names>> section can help.
+feature described in xref:spring-cloud-stream/functional-binding-names.adoc#functional-binding-names[Functional Binding Names] section can help.
 
 For example, if we want to give our `toUpperCase|wrapInQuotes` a more descriptive name we can do so
 with the following property `spring.cloud.stream.function.bindings.toUpperCase|wrapInQuotes-in-0=quotedUpperCaseInput` allowing
@@ -604,8 +604,8 @@ While trivial, this example demonstrates how one function enriches the incoming
 so the other function - `echo` - can benefit form it. The `echo` function stays clean and focused on business logic only.
 You can also see the usage of `spring.cloud.stream.function.bindings` property to simplify composed binding name. 
 
-[[functions-with-multiple-input-and-output-arguments]]
-=== Functions with multiple input and output arguments
+
+=== Functions with multiple input and output arguments [[functions_with_multiple_input_and_output_arguments]]
 
 Starting with version 3.0 spring-cloud-stream provides support for functions that
 have multiple inputs and/or multiple outputs (return values). What does this actually mean and
@@ -633,7 +633,7 @@ spring-cloud-stream and so on.
 So to accommodate all these requirements the initial support is relying on the signature which utilizes another abstraction
 provided by _Project Reactor_ - Tuples. However, we are working on allowing a more flexible signatures.
 
-IMPORTANT: Please refer to <<Binding and Binding names>> section to understand the naming convention used to establish _binding names_
+IMPORTANT: Please refer to xref:spring-cloud-stream/binding-names.adoc#binding-names[Binding and Binding names] section to understand the naming convention used to establish _binding names_
 used by such application.
 
 Let's look at the few samples: