Wrapping RS Elements using lazyBuilders - You can't use Subscribers/Processors more than once

[hutchig]

In issue #105 in this comment @jroper discussed the problem: As subscribers
are single use - what do we do if we have a Graph that imports a Subscriber (or Processor) and then we try to run/materialize it more than once? For example, if that Subscriber object got a onComplete() call - which 'run' would it be for?

The obvious answer is to: instead of importing a Subscriber instance we import a means of getting
a Subscriber (and similarly for Processor/Publisher in order to keep the API consistent). Java has a pattern for this, a Supplier. Of course we have a means to produce a Subscriber in the API already the SubscriberBuilder. So we probably want one of these that will attempt to supply a 'fresh' Subscriber each time it is run/materialized, perhaps a `lazy' SubscriberBuilder or as James termed it

SubscriberBuilder ReactiveStreams.lazySubscriberBuilder(Supplier<SubscriberBuilder>)

[hutchig]

The proposal to create a lazySubscriberBuilder that creates a usable Subscriber (i.e. one that is in the state 'has-never-been-subscribed-to-a-publisher') on build sort of suggests that we are
specifying that SubscriberBuilder.build (which returns a CompletionSubscriber subclass of Subscriber) does one or more of:

1 - is only valid to call once OR
2 - if it is called a second and subsequent time it returns the same CompletionSubscriber as a cached result without doing any additional method calls on any wrapped elements in the Graph's Stages.
3 - ~~ if it is re-run then the materialization can guarrantee that all parts of the Graph can
be re-materialized independantly. ~~ Plainly - this guarantee cannot be made - when, for example, there may be a ProcessorStage in the Graph created from ProcessorBuilder<T, S> via(Processor<? super R, ? extends S> processor); and the Engine knows nothing about the processor (apart from the fact it is NOT reusable).

I suggest that we document (in 1.0) that the result of materializing a stream more than once is undefined.

[Emily-Jiang]

We can think of a good use case.