Default format for coverage data is invalid

[barbuz]

Description
When requesting coverage data without specifying an output format we get an exception "Invalid format requested".

Steps to Reproduce
I have reproduced it locally, but this can be easily seen from the demo server:
stable: https://demo.pygeoapi.io/stable/collections/gdps-temperature/coverage
latest: https://demo.pygeoapi.io/master/collections/gdps-temperature/coverage

Expected behavior
We should get the data as json, the same result we get when appending ?f=json to the url
e.g. https://demo.pygeoapi.io/master/collections/gdps-temperature/coverage?f=json (can take up to a minute, add some filters to speed it up)

Screenshots/Tracebacks

Environment
Specs for my local deployment (I am not sure about the ones of the demo server)

• OS: Ubuntu 22.04
• Python version: 3.11.9
• pygeoapi version: 0.19.dev0

Additional context
This was working fine before version 0.16. I am not sure what introduced this bug.

From my initial investigation it appears that the format being passed is html, which is not a valid format for coverage.

[barbuz]

Turns out that the OGC specs specify using HTTP content negotiation to choose the output encoding for resources. This means that a bare request from a browser is going to receive an HTML answer since that is the format that is going to be requested in the headers by the browser.

However, neither of our coverage providers support HTML output, and it is not clear what kind of structure this output would have anyway, so they end up throwing an error instead of giving the user something useful. The OGC specs don't require HTML to be supported, so everything is adhering to them, but the result is less usable than it could be.

The solution to this could be to either add HTML support to the coverage providers (but we would need a good idea to define what this even means) or to revert back to the previous behaviour where a request that does not specify a format results in a coverageJSON output (less strictly following the specs but more useful to the users than the current situation).

I would be happy to provide a PR to implement the second option, but I would like to hear some opinion about this.