Deferred response headers should be handled more clearly from rhai

[garypen]

We currently provide map_response() from rhai, but any deferred responses don't contain headers and so trying to access them will result in an error.

This is a difficult situation to deal with. We have a few options:

1. Document this more clearly and rely on scripting to handle errors appropriately.
2. Provide access to alternative mapping mechanisms (e.g.: map_first_graphql_response()) and document it's use.
3. Modify the header accessing mechanisms to silently ignore operations on deferred responses.
4. ... ?

I think 1 is ok for now. I think 2 is the correct answer. I don't like 3, but we could consider it.

[garypen]

I have experimented with adding support for 2 and, to be honest, I don't think the DX is very good. I added map_first_response() support, which provided access to the headers, but you then have code that is calling map_first_response() and map_response() and you get overlap since both callbacks are invoked for the first response. So, then it becomes a question of should I add map_rest_response() and that becomes quite convoluted and feels like we are exposing too much complexity to the developer...

Perhaps 1 is the best answer. Just leave things as they are but clearly document that when handling responses, headers will not be present for deferred responses and that exceptions need to be handled.

[garypen]

The best way to address this is to improve the documentation and add the is_primary() method so that a script can determine at run time if a response is primary (i.e. has headers) or not.