Add notes about methods returning Future-like objects to Ft.2 and Ft.3

Author: leventov

README.md

@@ -1366,6 +1366,13 @@ has [multiple failure paths](#future-method-failure-paths): either the future ma
 exceptionally, or the method itself may throw an exception (typically from the blocking operation),
 which is illustrated by `getSalary() throws ConnectionException` in the above examples.
 
+This advice also applies when a method returns any object representing an asynchronous execution
+other than `Future`, such as [`Flow.Publisher`](
+https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/concurrent/Flow.Publisher.html
+), [`org.reactivestreams.Publisher`](
+https://www.reactive-streams.org/reactive-streams-1.0.3-javadoc/org/reactivestreams/Publisher.html),
+or RxJava's [`Observable`](http://reactivex.io/RxJava/javadoc/io/reactivex/Observable.html).
+
 <a name="future-method-failure-paths"></a>
 [#](#future-method-failure-paths) Ft.3. If a method returns a `Future` and some logic in the
 beginning of it may lead to an *expected failure* (i. e. not a result of a programming bug), **was
@@ -1399,6 +1406,10 @@ Future<Response> makeQuery(String query) {
 The point of this refactoring is unification of failure paths, so that the users of the API don't
 have to deal with multiple different ways of handling errors from the method.
 
+Similarly to [the previous item](#future-method-no-blocking), this consideration also applies when
+a method returns any object representing an asynchronous execution other than `Future`, such as a
+`Publisher`.
+
 ### Thread interruption and `Future` cancellation
 
 <a name="restore-interruption"></a>