* Upgrade to the latest dependencies
* Migrate assertions in tests to AssertJ
* Optimize tests to use unsafe mode for CP-subsystem
for better test execution performance
Fixes https://github.com/spring-projects/spring-integration-extensions/issues/235
According to the hazelcast team:
"The logic assumes that locks are generally acquired
& released in a fairly short time or hold a very long time without unlocking.
But in this case, is a bit different, it holds the lock for a long time,
but also does lock/unlock very frequently".
The previous implementation used the described logic,
first acquiring a lock and then doing frequent `tryLock/unlock`.
Doing this leads to
`com.hazelcast.cp.internal.datastructures.lockLock#ownerInvocationRefUids`
to grow without ever being cleaned thus leading to an `OutOfMemoryError` eventually.
* Rely on the `FencedLock.isLocked()` instead of frequent `tryLock/unlock`
* Fix `LeaderInitiatorTests` not to spawn 3 CP members since an unsafe mode is
enough to test the feature
* Move classes in this project to their own `kotlin` package
to avoid conflict with other Spring Integration artifacts
* Add lambda-based `handle()` instead of `GenericHandler` one
* Swap arguments in some EIP-method for better code flow
when build with Kotlin DSL
* Add a `scatterGatherFlow` configuration into a test suite
to demonstrate a complex configuration with Java API interoperability.
The Java sample is present in the comment for this flow definition
According Kotlin best practice it is better to not
extend from Java classes, but instead provide a
clean Kotlin API and delegate to Java one internally
* Implement all the `IntegrationFlowDefinition` methods
in the `KotlinIntegrationFlowDefinition` Kotlin way and
delegate to the provided `IntegrationFlowDefinition` instance
* Remove `@UseExperimental` and `@BuilderInference` since
we now have all the API in Kotlin
* Rework `KotlinDslTests` for support now Kotlin code style
* Remove `-Xuse-experimental` from Gradle config since we
don't use experimental API any more
It turns out that with `@BuilderInference` we don't need support
method chain flow in the builder implementation.
* Remove `KotlinIntegrationFlowDefinition` return type from its methods
It turns out that we can have a simple
`transform<String, String> { it.toLowerCase() }`
with extra parentheses around lambda and also another variant like
`split<String>({ p -> p }) { it.id("splitterEndpoint") }`.
Everything works with overloaded methods with and without extra
configurer parameter
* Upgrade dependencies, including Gradle
