removed timeout vs deadline explainer from retry_streaming

Author: daniel-sanche

google/api_core/retry/retry_streaming.py

@@ -147,75 +147,6 @@ class StreamingRetry(_BaseRetry):
     Although the default behavior is to retry transient API errors, a
     different predicate can be provided to retry other exceptions.
 
-    There are two important concepts that retry/polling behavior may operate on,
-    Deadline and Timeout, which need to be properly defined for the correct
-    usage of this class and the rest of the library.
-
-    Deadline: a fixed point in time by which a certain operation must
-    terminate. For example, if a certain operation has a deadline
-    "2022-10-18T23:30:52.123Z" it must terminate (successfully or with an
-    error) by that time, regardless of when it was started or whether it
-    was started at all.
-
-    Timeout: the maximum duration of time after which a certain operation
-    must terminate (successfully or with an error). The countdown begins right
-    after an operation was started. For example, if an operation was started at
-    09:24:00 with timeout of 75 seconds, it must terminate no later than
-    09:25:15.
-
-    Unfortunately, in the past this class (and the api-core library as a whole) has not
-    been properly distinguishing the concepts of "timeout" and "deadline", and the
-    ``deadline`` parameter has meant ``timeout``. That is why
-    ``deadline`` has been deprecated and ``timeout`` should be used instead. If the
-    ``deadline`` parameter is set, it will override the ``timeout`` parameter.
-    In other words, ``retry.deadline`` should be treated as just a deprecated alias for
-    ``retry.timeout``.
-
-    Said another way, it is safe to assume that this class and the rest of this
-    library operate in terms of timeouts (not deadlines) unless explicitly
-    noted the usage of deadline semantics.
-
-    It is also important to
-    understand the three most common applications of the Timeout concept in the
-    context of this library.
-
-    Usually the generic Timeout term may stand for one of the following actual
-    timeouts: RPC Timeout, Retry Timeout, or Polling Timeout.
-
-    RPC Timeout: a value supplied by the client to the server so
-    that the server side knows the maximum amount of time it is expected to
-    spend handling that specific RPC. For example, in the case of gRPC transport,
-    RPC Timeout is represented by setting "grpc-timeout" header in the HTTP2
-    request. The `timeout` property of this class normally never represents the
-    RPC Timeout as it is handled separately by the ``google.api_core.timeout``
-    module of this library.
-
-    Retry Timeout: this is the most common meaning of the ``timeout`` property
-    of this class, and defines how long a certain RPC may be retried in case
-    the server returns an error.
-
-    Polling Timeout: defines how long the
-    client side is allowed to call the polling RPC repeatedly to check a status of a
-    long-running operation. Each polling RPC is
-    expected to succeed (its errors are supposed to be handled by the retry
-    logic). The decision as to whether a new polling attempt needs to be made is based
-    not on the RPC status code but  on the status of the returned
-    status of an operation. In other words: we will poll a long-running operation until
-    the operation is done or the polling timeout expires. Each poll will inform us of
-    the status of the operation. The poll consists of an RPC to the server that may
-    itself be retried as per the poll-specific retry settings in case of errors. The
-    operation-level retry settings do NOT apply to polling-RPC retries.
-
-    With the actual timeout types being defined above, the client libraries
-    often refer to just Timeout without clarifying which type specifically
-    that is. In that case the actual timeout type (sometimes also referred to as
-    Logical Timeout) can be determined from the context. If it is a unary rpc
-    call (i.e. a regular one) Timeout usually stands for the RPC Timeout (if
-    provided directly as a standalone value) or Retry Timeout (if provided as
-    ``retry.timeout`` property of the unary RPC's retry config). For
-    ``Operation`` or ``PollingFuture`` in general Timeout stands for
-    Polling Timeout.
-
     Important Note: when a stream encounters a retryable error, it will
     silently construct a fresh iterator instance in the background
     and continue yielding (likely duplicate) values as if no error occurred.