fixes stack overflow possibility with merge operators

[geoffmacd]

Fixes #2615 See issue for details

when completing Merge operator iterations (concat(), concatMap() and merge(maxConcurrent:), fixes subscribing immediately to the next in the queue, which can produce values immediately which can re-enter and cause stack overflows. ultimately uses CurrentThreadScheduler and the isScheduleRequired prop to know if it needs to schedule or not. This is similar to Producer.

All tests pass

[danielt1263]

This looks like a good candidate for a dot release @freak4pc. What do you think?

[nikolaykasyanov]

I'm not sure how important this is, but scheduling the subscribe call will take the corresponding modification of self.parent.group out of the lock that is held while synchronized_on is executing.

[geoffmacd]

yea, I think you are right that there is an issue and I need to ensure the NSRecursiveLock is re-locking inside this block. I think for the current locking cycle from synchronized_on, there is no more mutation after this line to worry about. The lock will recursively lock on the next inner subscribe.

There is a separate issue here which is that the the disposable from _ = CurrentThreadScheduler.instance.schedule(()) needs to be added to the group otherwise this will not dispose if the CompositeDisposable is disposed. This is minor though since the parent.subscribe would have no impact.

[freak4pc]

Hey @geoffmacd, sorry for the long delay on this.

1. Did you use your own fix in prod by now? Is it stable?
2. Is the code ready from your perspective ?
3. Let's rebase / merge with main and have CI run all the tests to make sure we're good.

Thanks!

[geoffmacd]

Hey @freak4pc

Sorry for delay.

1. Yes this has been integrated in dropbox for 6 months which heavily uses Rx and is stable.
2. yes.
3. Will do.

[freak4pc]

Much appreciated, thank you :)

[geoffmacd]

ok, updated from main. ready to merge