[serve] remove support for nested DeploymentResponses

[zcin]

Why are these changes needed?

Remove support for passing DeploymentResponses in nested objects to downstream serve deployment handle calls, e.g:

handle.remote({"arg": other_handle.remote()})

This doesn't affect the no-op latency, but improves latencies of requests that carry a large payload.

Current handle latencies

New handle latencies:

{
  "handle_p50_latency": 1.7133924999939154,
  "handle_1mb_p50_latency": 2.931859499994971,
  "handle_10mb_p50_latency": 12.14768799999888,
}

Related issue number

closes #46428

Checks

• I've signed off every commit(by using the -s flag, i.e., git commit -s) in this PR.
• I've run scripts/format.sh to lint the changes in this PR.
• I've included any doc changes needed for https://docs.ray.io/en/master/.
  • I've added any new APIs to the API Reference. For example, if I added a
    method in Tune, I've added it in doc/source/tune/api/ under the
    corresponding .rst file.
• I've made sure the tests are passing. Note that there might be a few flaky tests, see the recent failures at https://flakey-tests.ray.io/
• Testing Strategy
  • Unit tests
  • Release tests
  • This PR is not tested :(

[edoakes]

@zcin let's make sure a good error message is raised if someone tries to pass a nested deployment response. You can do this by defining a __reduce__ method and raising an informative exception there.

[zcin]

@zcin let's make sure a good error message is raised if someone tries to pass a nested deployment response. You can do this by defining a __reduce__ method and raising an informative exception there.

@edoakes Added an informative error message in __reduce__ of DeploymentResponse, PTAL!

[edoakes]

@zcin let's make sure a good error message is raised if someone tries to pass a nested deployment response. You can do this by defining a __reduce__ method and raising an informative exception there.

@edoakes Added an informative error message in __reduce__ of DeploymentResponse, PTAL!

Let's add a test for it too, then LGTM