prepare 5.0.0-rc2 release

[eli-darkly]

[5.0.0-rc2] - 2020-05-13

The primary purpose of this second beta release is to introduce the new DataSourceStatusProvider API, which is the server-side equivalent to the "connection status" API that exists in LaunchDarkly's mobile SDKs. Other additions and changes since the previous beta release (5.0.0-rc1) are described below. See the 5.0.0-rc1 release notes for other changes since 4.13.0.

Added:

• LDClient.getDataSourceStatusProvider() is a status monitoring mechanism similar to getDataStoreStatusProvider(), but for the data source (streaming, polling, or file data). You can not only check the current connection status, but also choose to receive notifications when the status changes.
• LDConfig.Builder.logging() is a new configuration category for options related to logging. Currently the only such option is escalateDataSourceOutageLoggingAfter, which controls the new connection failure logging behavior described below.
• LDConfig.Builder.threadPriority() allows you to set the priority for worker threads created by the SDK.

Changed:

• Network failures and server errors for streaming or polling requests were previously logged at ERROR level in most cases but sometimes at WARN level. They are now all at WARN level, but with a new behavior: if connection failures continue without a successful retry for a certain amount of time, the SDK will log a special ERROR-level message to warn you that this is not just a brief outage. The amount of time is one minute by default, but can be changed with the new logDataSourceOutageAsErrorAfter option in LoggingConfigurationBuilder.
• The number of worker threads maintained by the SDK has been reduced so that most intermittent background tasks, such as listener notifications, event flush timers, and polling requests, are now dispatched on a single thread. The delivery of analytics events to LaunchDarkly still has its own thread pool because it is a heavier-weight task with greater need for concurrency.
• In polling mode, the poll requests previously ran on a dedicated worker thread that inherited its priority from the application thread that created the SDK. They are now on the SDK's main worker thread, which has Thread.MIN_PRIORITY by default (as all the other SDK threads already did) but the priority can be changed as described above.
• Only relevant for implementing custom components: The DataStore and DataSource interfaces, and their factories, have been changed to provide a more general mechanism for status reporting. This does not affect the part of a persistent data store implementation that is database-specific, so new beta releases of the Consul/DynamoDB/Redis libraries were not necessary.