Refine and clarify operations in asynchronous caching implementation

See Issue #2650

See Original Pull Request #2717

Uses more descriptive names for operations, especially Reactive operations, by either calling a local, private method or introducing a variable with strongly typed parameters.

For example, this Function<ReactiveRedisConnection, Mono<T>> commandExecution is more readable and descriptive than it -> Mono.fromCompletionStage(callback.apply(it)) buried in some Reactive Publisher (e.g. Flux) operation. Outside of the IDE (such as reading source in GitHub), I immediately know that "it" is a Redis (Reactive) connection, that I am executing a Redis command and that I can safely assume I am getting back a Mono of T (the value returned from the "reactive" command execution).

In some case (perhaps many cases) Reactive programming obscures the actions that are actually happening (such as looping until some condition is met), particularly in "concurrent" fashion, making the code more difficult to understand. Without, proper naming and organization, understanding is greatly diminished and even readability is compromised.

Edits Javadoc.