Make StreamableClientTransport less strict by default

[findleyr]

Internal users at Google are reporting problems using the StreamableClientTransport to communicate with various backends, because it is strict and fails the connection at the first spec violation it observes. In some cases, these violations are recoverable. We should make the client less strict by default, because it should do the best it can and work as often as possible.

For example:

• If the hanging GET encounters 404 instead of 405, it treats it as a signal that the session is not found and closes the connection (this was also reported externally as failed to reconnect: Not Found after initalize in stateless HTTP POST server #393. We can treat a 404 like a 405 for the hanging GET.
• If the server returns 200 instead of 202 for a notification or response, we try to read the body and fail. Again, the spec says that servers must return 202, but if we know there should be no response content we can treat a 200 equivalently.

Now, I think we should also have a "strict mode", but that can be enabled by StreamableClientTransport.Strict. Will leave that to another proposal.

[samthanawalla]

I think this is a good idea.

What do you think about creating a flag for each violation and deprecating it over time? I think a single bool hides the violations and makes it harder to maintain over time.

[findleyr]

@samthanawalla I don't think we need to decide this immediately, since the option is not (yet) exported.

Though, generally, I think it's too finicky to have a flag for every violation. I think there are two use cases: "just do the best you can", and "ensure that this server is conforming to the spec". I can't imagine a scenario where you'd want to allow certain recoverable spec violations, but not others.

[jba]

I wish strict were the default, but I guess the ecosystem is already too big for that.

[samthanawalla]

Fair enough!