Prepare 0.39.0

[p4checo]

Description

Cherry pick of upstream commits up to version 0.39.0 🏷️:

• Concurrency Beta (#1189) 108e3a5

Discussion

Breaking changes due to Effect no longer typealiasing SignalProducer

This update will cause countless breaking changes in projects as Effect is now a struct that wraps a SignalProducer instead of being a typealias of it. This is not as big of a problem in upstream TCA because Effect is still a Publisher, so all Combine operators will keep working on Effect operation chains, whereas in RAS-TCA they will now break.

Possible approaches:

1. Follow upstream approach

• Pros:
  • People will be (forcibly 😅) steered away from SP-based effects in favor of the new async based ones quicker
• Cons:
  • Harder migration path, especially in reducers that use RAS operators and dependencies that use Effect outputs
  • Difficult to provide deprecation warnings with Fix-Its

2. Create RAS variants of SignalProducer's operators in Effect~

• Pros:
  • Almost no breaking changes (if we cover most/all operators)
• Cons
  • Increases API surface area
  • Increases stack sizes, as each operator would have to do a .producer.doOperation().eraseToEffect()
  • Projects will likely take longer to migrate away from using SPs as the building block of their Effects

3. Add SignalProducerConvertible conformance to Effect

• Pros:
  • Smoother transition, by providing a simple "fix" to make things build again (i.e. add a .producer in relevant chains)
• Cons
  • Would still be breaking change, as people still need to use a .producer on the chain before using any RAS operators
  • Requires exposing the wrapped producer as public (requirement of SignalProducerConvertible), which is not ideal
  • Projects will likely take longer to migrate away from using SPs as the building block of their Effects

4. other?

TestScheduler

Pointing to ReactiveSwift 7.1, which already includes async APIs in TestScheduler and DateScheduler.

Upstream TCA relies on `CombineScheduler`'s `[TestScheduler](https://github.com/pointfreeco/combine-schedulers#testscheduler)` to control scheduling in unit tests, and they have added `async` variants of the `advance(by:)`, `advance(to:)` and `run()` as well as helper `sleep` and `timer` async APIs.

1. For now I've left all await mainQueue.advance() and await mainQueue.run()calls in place. It triggers a warning but most tests pass, except those where the reducer uses the new sleep or timer async APIs on effects, which fail. .
2. I've implemented the sleep and timer async APIs in SchedulerExtensions for now.

I opened ReactiveCocoa/ReactiveSwift#857 to add these new async APIs which are required to properly test new async effects that wait on time, as well as help make the transition to Clock APIs smoother as well.

New SignalProducerConvertible.values Async(Throwing)Stream APIs

In order to use SignalProducers in the async "world", while replicating the existing APIs in Combine, two new
values computed properties in SignalProducerConvertible were added:

• values: AsyncStream<Value> when Error == Never
• values: AsyncThrowingStream<Value, Swift.Error> otherwise

Implementation was heavily inspired by ReactiveCocoa/ReactiveSwift#847, the main difference is that these extensions were added to SignalProducerConvertible instead of SignalProducer. This allows having defining both properties with the same name while providing symmetry with Combine.

Thoughts? 🙏🏼