Fix scope leak with Stream.retry and in general, with pulls that do...

[mpilquist]

…not consume all elements from source.

Some observations prior to this PR:

// No leak:
Stream.eval(IO.unit).attempt.repeat.compile.drain.unsafeRunSync()

// Leaks in 2.1.0+, does not leak in 2.0.1:
Stream.eval(IO.unit).attempts(Stream.constant(1.second)).head.repeat.compile.drain.unsafeRunSync()

// Leak fixed by inserting an explicit scope after head
Stream.eval(IO.unit).attempts(Stream.constant(1.second)).head.scope.repeat.compile.drain.unsafeRunSync()

The reason a leak was introduced in 2.1.0 is that handleErrorWith was modified to introduce a scope. The use of head, which is an alias for take(1), is implemented with a pull that discards the remainder of the stream once a single output element has been output. This has the effect of discarding the release of the scope opened by handleErrorWith.

More generally, any pull which discards the remainder of the stream has the potential of causing a similar scope leak. Hence, this PR returns to the FS2 1.0.x design of introducing a scope every time a pull is converted to a stream. Doing so causes the scope introduced by handleErrorWith to be a child scope of the pull-to-stream scope, and hence, when the pull-to-stream scope is closed, all descendant scopes are closed too.

[mpilquist]

Without this change, the test for resourceWeak fails b/c there's a map in the implementation of resourceWeak. It's okay to not have a scope here b/c this pull consumes the entire source stream. Note back in 1.0.5, we had this same definition of map and it was the only such invocation in the library. So while this does feel a bit ad-hoc, we also have the most mileage on it.

[SystemFw]

Very clear explanation, I hadn't fully read it yesterday :)