Add "single" as alternative for observables that only emit once or error and then complete

Feature Request

A special type for observable that only emits one value or throws error and then completes.

Is your feature request related to a problem? Please describe.
The Angular HTTPClient returns observables for http requests, but you can be sure they will complete after one emission/error. I already saw people wrapping those observables in a Promise just to "make sure / emphasis" it will emit once (by the return type Promise). As trade off you loose the nice rxjs observables api (pipes etc.).

Describe the solution you'd like
The Java Implementation of Rx provides a special type for this use case called "Single".
http://reactivex.io/documentation/single.html
I know Java might not be the best source for inspiration, but in this case the additional type could provide useful additonal type information for consumers. There are things that "by nature" do not return a stream of multiple values but only one e.g. a http request.

The first sentence in rxjs documentation on observables states:

Observables are lazy Push collections of multiple values.

As beginner you can easily get confused by a http request returning an observable and therefore somehow emitting multiple values (multiple = more than one).

I can understand that such "Single" type could on the other hand cause some trouble for beginners because it seems to be something similar to a Promise. But imho it would be nice to have such a type with a subset of rxjs operators you already know from observables. The subset of operators would not include the operators that depend on the emission of multiple values or don't make sense for a single value (take, pairwise, ...).

Describe alternatives you've considered
If a new type like "Single" can not be taken into consideration, at least the documentation should be adjusted to clarify that observables can also emit 0 or only 1 value.

Additional context
What would be the reasons against having a new type of observables like single?

• More complex to understand for beginners?
• Bigger footprint of the library?
• Confusion with existing promise implementation?
• What else?

There were already discussions about similar topics in #2469 and #3424 but I couldn't find reasonable arguments against it, yet.

Start by reviewing the existing RxJS observable documentation and the related discussions in #2469 and #3424. Determine whether the request needs a new Single-like API or only clearer documentation; done requires an agreed scope and design direction, since this issue does not name implementation files or tests.