## Motivation
The API for establishing the configuration of a connection pool had a lot of jargon and properties that developers had issues keeping straight and understanding what each does.
This commit provides first-class API support for concepts such as retry strategies, and how the pool handles connection counts.
## Changes
- Add: New ConnectionCountBehavior for determining leaky / non-leaky behavior
- Add: New ConnectionRetryStrategy for allowing customization of retry behavior
- Change: RedisConnection.defaultPort to be a computed property
- Change: The logging keys of pool connection retry metadata
- Rename: Several configuration properties to drop prefixes or to be combined into new structures
## Result
Developers should have a much better experience exploring the available configuration options for pools and connections, being able to understand how each piece works with the underlying system.
There are many times that developers want exact control over which EventLoop will be executing their chained EventLoopFuture callbacks
and which Logger will do the logging in calls deep within RediStack.
All commands will now accept an optional EventLoop and Logger to hop to, and using the logger for desired logs.
The newly-released Service Discovery framework gives us the interesting
opportunity to make RediStack aware of complex service discovery tools.
This patch supplies a simple adaptor to integrat Service Discovery with
RediStack's pooled client, allowing users to work with arbitrary service
discovery systems.
Motivation:
The original implementation of Logging was done in more haste than should have been, without proper attention given to the semantic requirements.
As the Swift ecosystem has matured a bit, lessons have been learned on handling metadata and passing of external context into internal subcomponents.
A mixture of the "protocol-based context passing" and "explicit context passing" patterns have been adopted.
Both patterns are more fully described in the Swift forum discussion: https://forums.swift.org/t/the-context-passing-problem/39162
Modifications:
- Add: `RedisLogging` namespace with references to static keys and labels that are used for Logging throughout the library
- Add: `Logger` static computed properties to access the Logger prototypes used in connection and connection pools
- Add: `RedisClientWithUserContext` protocol and `UserContextRedisClient` types to assist with wrapping client types for custom logger contexts
- Remove: `logger` property from `RedisClient` requirements
- Change: Many log statements to have higher or lower log levels for their appropriate context
- Change: `RedisConnection` and `RedisConnectionPool` to conform to `RedisClientWithUserContext`
- Change: `logging(to:)` protocol requirement to return a `RedisClient` existential
- Change: ConnectionPool to explicitly pass a logger instance around for pooling methods
Result:
Logging in RediStack will now have a stronger contract of where and how logs will be generated and which context will be used.
Fixes#79 and #74
Nathan Harris
Fabian Fett
Nathan Harris
Cory Benfield