Response parameters type hints

[OldSneerJaw]

Related to #173.

Makes improvements to the type hints of response parameters in both MockerCore and Adapter:

• Added explicit parameters for reason, cookies, json, content, body, raw and exc as per the documentation at https://requests-mock.readthedocs.io/en/latest/response.html#registering-responses
• Updated the text parameter to support static and dynamic values as per https://requests-mock.readthedocs.io/en/latest/response.html#dynamic-response
• Ensured that the "new" json, content and body parameters support both static and dynamic values, just like the text parameter

Also, as per @jamielennox's suggestion, I added "single star" parameters from PEP 3102 to indicate where the list of keyword-only arguments begin in both MockerCore and Adapter.

[jamielennox]

It does appear that all the dynamic typing that was done for the API makes getting type annotations right for this pretty challenging :)

Out of interest - it doesn't appear here that having _Context and _RequestObjectProxy as private makes any difference? At one point someone had asked to make them public as it would simplify some IDE things.

[jamielennox]

interesting - i always thought this was callable as well. Guess noone has ever used that.

[OldSneerJaw]

@jamielennox wrote:

It does appear that all the dynamic typing that was done for the API makes getting type annotations right for this pretty challenging :)

Out of interest - it doesn't appear here that having _Context and _RequestObjectProxy as private makes any difference? At one point someone had asked to make them public as it would simplify some IDE things.

Making the types public would help users of the API to annotate their own callback functions. As it is, a linter (e.g. pylint) might complain at the use of private types in the parameter annotations. For example, if I were to write my own text callback with type annotations, I might do something like this (borrowed and tweaked from the docs):

def text_callback(request: _RequestObjectProxy, context: _Context) -> str:
    context.status_code = 200
    context.headers['Test1'] = 'value1'
    return 'response'

Of course, changing the _RequestObjectProxy type name would technically be a breaking change for API clients that have already written any dynamic additional_matcher functions and annotated the parameters with _RequestObjectProxy. You could get around that issue by renaming _RequestObjectProxy to RequestObjectProxy and then adding a replacement _RequestObjectProxy that extends from it with an empty body, for example. On the bright side, I don't think it's an issue for _Context at this point since these new annotations haven't actually been released yet.