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
To avoid some inline reified functions names, it would be better to rely
on the `BaseIntegrationFlowDefinition` from SI Core.
This way we can have the same names for Kotlin-specific functions
without conflicts for similar methods in Java which are just a syntax
sugar without any target type guarantee
* * Add `KotlinIntegrationFlowDefinition` as an extension of `BaseIntegrationFlowDefinition`
to be able to provide inline functions for reified generic types.
* Use this new type from the `integrationFlow()` DSL functions to avoid
extra imports for global inline functions otherwise
* * Improve README
