* Add named caches and apply to NonInvalidingUnboundCache and all usages.
* Add named caches and apply to NonInvalidingCache and all usages.
* Add named caches and apply to NonInvalidingWeightBasedCache and all usages.
* Move NamedCache to core/internal
* Remove type `NamedCache` and `NamedLoadingCache`
* Suppressed 'name not used' warning, added comment, and fixed generic parameters on the buildNamed functions.
* Use `buildNamed` in all caffeine instances in production code. Not using it for caches that are created in test code.
* Add checks for the cache name
* Formatting
* Minor code review revisions
* CORDA-1844: Exposing a problem via Unit test.
* CORDA-1844: Unit test update following input from Andras.
* CORDA-1844: Add optional parameter to reduce the time it takes to shutdown RPCServer.
* CORDA-1844: Add optional parameter to reduce the time it takes to shutdown RPCServer and sensibly default it.
Minor changes.
* Eliminate un-necessary reference to Kryo in the comment
* RPC documentation update.
* Rename RpcClientObservableSerializer into RpcClientObservableDeSerializer
They're prone to cause flaky tests due to the "allocated" ports already being taken by the system when eventually needed. Replaced usages with PortAllocation.Incremental.
Affected unit tests made into integration tests to avoid any issues in the future when unit tests are made to run in parallel.
* CORDA-1743: Remove `isDebug = true` from Node driver to speed-up integration tests execution.
* CORDA-1743: Undo removal of "isDebug = true" from the test that specifically checks for this condition.
* CORDA-1743: Address input from @shamsasari
This requires the class carpenter to be able to run in a "lenient" mode where it permits synthesised classes to implement interfaces with unimplemented methods.
As reported in [CORDA-1609](https://r3-cev.atlassian.net/browse/CORDA-1609),
`CordaRPCClientConfiguration.default` is not accessible from Java since
`default` is a reserved keyword.
As part of the refactor made in #2831, `CordaRPCClientConfiguration` went
from being a data class to an interface with a backing implementation of
type `CordaRPCClientConfigurationImpl`.
This resulted in Java users having to rewrite code that was on the form:
```java
final CordaRPCClient client = new CordaRPCClient(
nodeAddress, CordaRPCClientConfiguration.DEFAULT
);
```
to something like this:
```java
final CordaRPCClient client = new CordaRPCClient(
nodeAddress, CordaRPCClientConfiguration.Companion.default()
);
```
However, this does not work. The user would get a compilation error because
`default` is a reserved keyword in Java.
Since `CordaRPCClientConfiguration` has been made an interface, there is no
easy way of introducing a static final field on the interface from Kotlin.
Consequently, I've changed this back to using a `class` with a static field
named `DEFAULT` instead of the static method `default()`.
It should be noted that `default()` / `DEFAULT` is currently only used
internally to pass in default values in `CordaRPCClient.kt` and
`CordaRPCClientUtils.kt`. That said, it is exposed as part of our API
surface and consequently shouldn't be broken.
The latter means that in the above example, the user would actually not
have to provide the parameter at all:
```java
final CordaRPCClient client = new CordaRPCClient(nodeAddress);
```
As can be seen from the definition of `CordaRPCClient`:
```kotlin
class CordaRPCClient private constructor(...) {
@JvmOverloads
constructor(
hostAndPort: NetworkHostAndPort,
configuration: CordaRPCClientConfiguration = CordaRPCClientConfiguration.DEFAULT
) : this(hostAndPort, configuration, null)
```
The mentioned [refactor](7a077e76f0 (diff-0948c125db93a22263eb81eaf3161c17R65))
did not make it into the 3.1 release, so from an API-stability perspective,
this change can be applied without affecting our commitment to a
backwards compatible API..
