Confusing behavior when allow_fetching is True

The docstring of context.ValidationContext states that if the value of the allow_fetching parameter is True "and certificates contain the location of a CRL or OCSP responder, an HTTP request will be made to obtain information for revocation checking". The word "allow" seems to indicate that this HTTP request is merely an additional way of obtaining information about revocation status. Moreover, also the following comment (especially the word "also") suggests that CRL or OCSP data requested via HTTP are not the only source of revocation status information if allow_fetching is True:

https://github.com/wbond/certvalidator/blob/5bc5c390c1955195507c23db91b8926bb03f7385/certvalidator/context.py#L87-L90

The docstring of the crls and ocsps parameters explain that pre-fetched/cached CRL and/or OCSP data can be passed to ValidationContext.

Putting all together, it seems that setting the allow_fetching parameter to True may result in fetching CRL or OCSP data in addition to checking pre-fetched/cached data.

Contrary to this expectation, if ValidationContext._allow_fetching is True, pre-fetched/cached CRL and OCSP data (passed by the crls and ocsps parameters) are completely ignored. (See the crls and ocsps properties and the retrieve_crls and retrieve_ocsps methods of ValidationContext.) If that is the intended behavior, it should be clarified in the documentation. Otherwise - and I would except this more intuitive - the two sources of revocation information should be merged when this is appropriate.

Start in context.py with the crls and ocsps properties and the retrieve_crls and retrieve_ocsps methods, then compare their behavior with the ValidationContext docstrings and comments. Determine whether allow_fetching should ignore or merge pre-fetched revocation data; done means the chosen behavior is implemented or clearly documented, with relevant tests updated if present.