Asynchronous vs Synchronous Processing: rephrase "MUST NOT block the Publisher"

[anthonyvdotbe]

The section Asynchronous vs Synchronous Processing starts with the following sentence:

The Reactive Streams API prescribes that all processing of elements (onNext) or termination signals (onError, onComplete) MUST NOT block the Publisher.

However, there's no occurrence in the specification of the term "block". Moreover, in the rules about responsivity (2.2, 3.4, 3.5), only 3.5 says Subscription.cancel MUST respect the responsivity of its caller, while the others use RECOMMENDED/SHOULD.
Also, to avoid any confusion, I believe the binding words from RFC2119 must be avoided outside the rule tables.

Therefore I propose to change this to:

The Reactive Streams API prescribes that all processing of elements (onNext) or termination signals (onError, onComplete) should respect the responsivity of the Publisher [see 2.2].

For reference, replies from within #177 by @akarnokd:

"not block": sounds a bit harsh. It is supposed to indicate that one should avoid sleeping, waiting on an object or condition, because those can be written in a notification-like (i.e., push) fashion.

and @viktorklang:

"block" may not have been the best word, and it should most definitely be explained, but the intent is that a Subscriber should not impede the progress of the Publisher from an execution PoV. I.e. the Subscriber should not starve the Publisher from CPU cycles.

[viktorklang]

AFAIK addressed by the glossary in #339