Introduce IntegrationPattern abstraction

* Add `IntegrationPattern` contract to implement on the target components
which represent particular EIP
* Add `IntegrationPatternType` with an internal `IntegrationPatternCategory`
to return from the component implementing `IntegrationPattern`
* Parse `IntegrationPatternType` in the `IntegrationNode` for potential
use on the UI for drawing a particular icon

* More pattern representations

* Clean up Checkstyle
* Fix JavaDocs
* Add `integrationPatternCategory` assertion into the `IntegrationGraphServerTests`

* Add more IntegrationPattern implementations
* Provide some delegation and overriding logic whenever we have
components wrapping

* Fix unused imports

* Add `inbound_gateway` pattern indicator
* Add conditional on `expectReply` to indicate a component as an
`IntegrationPatternType.outbound_channel_adapter` or
`IntegrationPatternType.outbound_gateway`
* Make some code clean up in affected classes

* Add a `gateway` type for `@MessagingGateway`

* Comment the reason for `outbound_gateway` type in the `AbstractReplyProducingMessageHandler`
* Bump `IntegrationGraphServer.GRAPH_VERSION`
* Add new attributes into graph sample in the `graph.adoc`
* Document an `IntegrationPattern`

* Apply changes for version 5.3

* Rebased into `5.3-WIP`
* Add a `whats-new.adoc` note about an `IntegrationPattern`

src/reference/asciidoc/graph.adoc

@@ -14,13 +14,15 @@ A Spring Integration application with only the default components would expose a
 {
   "contentDescriptor" : {
     "providerVersion" : "{project-version}",
-    "providerFormatVersion" : 1.1,
+    "providerFormatVersion" : 1.2,
     "provider" : "spring-integration",
     "name" : "myAppName:1.0"
   },
   "nodes" : [ {
     "nodeId" : 1,
     "componentType" : "null-channel",
+    "integrationPatternType" : "null_channel",
+    "integrationPatternCategory" : "messaging_channel",
     "properties" : { },
     "sendTimers" : {
       "successes" : {
@@ -42,6 +44,8 @@ A Spring Integration application with only the default components would expose a
   }, {
     "nodeId" : 2,
     "componentType" : "publish-subscribe-channel",
+    "integrationPatternType" : "publish_subscribe_channel",
+    "integrationPatternCategory" : "messaging_channel",
     "properties" : { },
     "sendTimers" : {
       "successes" : {
@@ -59,6 +63,8 @@ A Spring Integration application with only the default components would expose a
   }, {
     "nodeId" : 3,
     "componentType" : "logging-channel-adapter",
+    "integrationPatternType" : "outbound_channel_adapter",
+    "integrationPatternCategory" : "messaging_endpoint",
     "properties" : { },
     "output" : null,
     "input" : "errorChannel",
@@ -219,13 +225,14 @@ The preceding gateway produces nodes similar to the following:
 
 ====
 [source,json]
-
 ----
 {
   "nodeId" : 10,
   "name" : "gate.bar(class java.lang.String)",
   "stats" : null,
   "componentType" : "gateway",
+  "integrationPatternType" : "gateway",
+  "integrationPatternCategory" : "messaging_endpoint",
   "output" : "four",
   "errors" : null
 },
@@ -234,6 +241,8 @@ The preceding gateway produces nodes similar to the following:
   "name" : "gate.foo(class java.lang.String)",
   "stats" : null,
   "componentType" : "gateway",
+  "integrationPatternType" : "gateway",
+  "integrationPatternCategory" : "messaging_endpoint",
   "output" : "four",
   "errors" : null
 },
@@ -242,6 +251,8 @@ The preceding gateway produces nodes similar to the following:
   "name" : "gate.foo(class java.lang.Integer)",
   "stats" : null,
   "componentType" : "gateway",
+  "integrationPatternType" : "gateway",
+  "integrationPatternCategory" : "messaging_endpoint",
   "output" : "four",
   "errors" : null
 }
@@ -251,6 +262,9 @@ The preceding gateway produces nodes similar to the following:
 You can use this  `IntegrationNode` hierarchy for parsing the graph model on the client side as well as to understand the general Spring Integration runtime behavior.
 See also <<./overview.adoc#programming-tips,Programming Tips and Tricks>> for more information.
 
+Version 5.3 introduced an `IntegrationPattern` abstraction and all out-of-the-box components, which represent an Enterprise Integration Pattern (EIP), implement this abstraction and provide an `IntegrationPatternType` enum value.
+This information can be useful for some categorizing logic in the target application or, being exposed into the graph node, it can be used by a UI to determine how to draw the component.
+
 === Integration Graph Controller
 
 If your application is web-based (or built on top of Spring Boot with an embedded web container) and the Spring Integration HTTP or WebFlux module (see <<./http.adoc#http,HTTP Support>> and <<./webflux.adoc#webflux,WebFlux Support>>, respectively) is present on the classpath, you can use a `IntegrationGraphController` to expose the `IntegrationGraphServer` functionality as a REST service.

src/reference/asciidoc/whats-new.adoc

@@ -15,6 +15,11 @@ If you are interested in more details, see the Issue Tracker tickets that were r
 [[x5.3-new-components]]
 === New Components
 
+[[x5.3-integration-pattern]]
+==== Integration Pattern
+
+The `IntegrationPattern` abstraction has been introduced to indicate which enterprise integration pattern (an `IntegrationPatternType`) and category a Spring Integration component belongs to.
+See its JavaDocs and <<./graph.adoc#integration-graph,Integration Graph>> for more information about this abstraction and its use-cases.
+
 [[x5.3-general]]
 === General Changes
-