docs/guides/deadlines: Replace "request" with "RPC" (grpc#1336)

Not all usages of request were changed, but any that were talking about
the deadline of a request were changed, because requests don't have
deadlines. Only RPCs have deadlines.

I also made it more clear at which point a timeout would start from
within gRPC.

Author: ejona86

Diff for: content/en/docs/guides/deadlines.md

@@ -15,9 +15,10 @@ improve the resource utilization and latency of your system.
 
 Note that while some language APIs have the concept of a __deadline__, others
 use the idea of a __timeout__. When an API asks for a deadline, you provide a
-point in time which the request should not go past. A timeout is the max
-duration of time that the request can take. For simplicity, we will only refer
-to deadline in this document.
+point in time which the call should not go past. A timeout is the max duration
+of time that the call can take. A timeout can be converted to a deadline by
+adding the timeout to the current time when the application starts a call. For
+simplicity, we will only refer to deadline in this document.
 
 ### Deadlines on the Client
 
@@ -33,24 +34,24 @@ will give up and fail the RPC with the `DEADLINE_EXCEEDED` status.
 
 ### Deadlines on the Server
 
-A server might receive requests from a client with an unrealistically short
+A server might receive RPCs from a client with an unrealistically short
 deadline that would not give the server enough time to ever respond in time.
 This would result in the server just wasting valuable resources and in the worst
 case scenario, crash the server. A gRPC server deals with this situation by
 automatically cancelling a call (`CANCELLED` status) once a deadline set by the
 client has passed.
 
 Please note that the server application is responsible for stopping any activity
-it has spawned to service the request. If your application is running a
-long-running process you should periodically check if the request that initiated
+it has spawned to service the RPC. If your application is running a
+long-running process you should periodically check if the RPC that initiated
 it has been cancelled and if so, stop the processing.
 
 #### Deadline Propagation
 
 Your server might need to call another server to produce a response. In these
 cases where your server also acts as a client you would want to honor the
 deadline set by the original client. Automatically propagating the deadline from
-an incoming request to an outgoing one is supported by some gRPC
+an incoming RPC to an outgoing one is supported by some gRPC
 implementations. In some languages this behavior needs to be explicitly
 enabled (e.g. C++) and in others it is enabled by default (e.g. Java and Go).
 Using this capability lets you avoid the error-prone approach of manually
@@ -108,4 +109,4 @@ sequenceDiagram
 
 - [Deadlines blogpost]
 
-[Deadlines blogpost]: https://grpc.io/blog/deadlines/
+[Deadlines blogpost]: https://grpc.io/blog/deadlines/