This change needs a formal gRFC.

/cc @hsaliak

@ZhouyihaiDing this is an API change, so we should consider it carefully. The process to change it is necessarily heavy weight. However, since the API is not in yet, this is pretty much the last chance to change it.
So let's consider this change here before we decide if we want to re-visit the RFC.

1. Why will the response type change cause the deserializer change? Isnt the de-serializer fixed to how the response is encoded, rather than what the data is?
2. Do you have some use cases where we have encountered this?
   Normally, interceptors contain cross cutting concerns rather than business logic, so they only mutate data rarely.. so how often do you see users get into a problem with the current API?
3. How do other languages do this, do they provide a deserializer?

Oh I already created a PR to the grpc/proposal repo. I think we can close that if the change is no needed?

It's a thing better to have, because it won't do any harm to the interceptor. To my understand, interceptor can intercept everything related to the RPC except the channel.
But it is also unnecessary, because I can't image why the user want to the deserializer.

The reason I have this idea is when I implementing the gcp extension(kind of like a plugin to the gRPC), which need to maintain it's own channel pool and do pre/post process for each RPC. This could be done by the interceptor, but since the Call and the Channel are bound too tight, I need 2 more API changes to do the similar thing. #15761 and #15749.

The purpose of this PR is decouple the RPC and Channel, kind of like CallInvoker in C# does. If we give the $deserialize back to the RPC, then the interceptor will have everything needed for creating a Call object. But this is kind of tricky because this is not the usual way to use the interceptor.

I finished the implementation which only uses the interceptor to hook the GCP extension support with the change of this PR: ZhouyihaiDing#22. The GCP interceptor is implemented with self maintained channel and call, which is exactly what CallInvoker implementation is doing.
I chatted with @mehrdada offline and we could merge this to 1.13.0 by state "There is an experimental API and there is a proposal under the review".

CallInvoker implemetation needs to add 2 more APIs change as described above to de-couple the channel and the call object from the stub. However, it makes the GCP implementation be hooked in a more clear way.

I am okay with adding CallInvoker and changing the interceptor, because CallInvoker will make the GCP extension looks more directly(and since the C# has it, maybe PHP can have it too), while the Inteceptor changes is doing the least changes to the grpc php code.

Hi, @chingor13 @michaelbausor
I am going to update the API for the interceptor to decouple the Call object and Channel object. Can you please give me some suggestions if there are some concerns relate to it? Thanks!

Sorry. I used the rebase in a wrong way and it was trying to commit tons of commits into the v1.13.x branch.

Known issues for the test:
Bazel Debug build for C/C++ - #15610
Bazel Opt build for C/C++ - #15610