Handle WFS version mismatch

[JakobMiksch]

• fixes Malformed WFS Capabilities causes cryptic stack trace #1036
• new functionality: if the requested version of a WFS does match the received WFS version in the XML, a CapabilitiesError will be raised
• I had to adapt one other failing test, that requested WFS 1.1.0 but the received a WFS 1.0.0

[geographika]

Nice work - thanks @JakobMiksch ! Unless @tomkralidis has any further comments I'll merge in a day or so.

[domlowe]

Just to say that the WFS version negotiation rules do allow the server to return alternative versions:
https://docs.ogc.org/is/04-094r1/04-094r1.html#15

But it is essentially a client decision how to deal with alternative versions - e.g. whether to accept it, ask for an alternative or cease communicating (as is the case in this PR).

[geographika]

Thanks for the details @domlowe. The warning is an improvement on simply failing when parsing using the incorrect class.
@JakobMiksch - what happens if no version is sent with the GetCapabilities request? I guess it uses the default "1.0".

[JakobMiksch]

@geographika

what happens if no version is sent with the GetCapabilities request? I guess it uses the default "1.0".

It would raise an exception as well. I have not handled this case.

[JakobMiksch]

Just to say that the WFS version negotiation rules do allow the server to return alternative versions: https://docs.ogc.org/is/04-094r1/04-094r1.html#15

But it is essentially a client decision how to deal with alternative versions - e.g. whether to accept it, ask for an alternative or cease communicating (as is the case in this PR).

If users rely on the current functionality, we could hide the new check behind a new opening argument, that is False by default. Something like this maybe:

wfs = WebFeatureService(
   url="https://www.geoproxy.geoportal-th.de/geoproxy/services/STRNETZ_wfs", 
   version="1.0.0", 
   strict_version=False # <-- NEW OPTIONAL ARGUMENT
)