Retry GET calls within _request method 5 times before giving up, and fix coverage

[goessebr]

The coverage tests on the master branch are broken.

The code in

skosprovider_atramhasis/skosprovider_atramhasis/providers.py

Lines 266 to 267 in a4f9762

	if not res.encoding:
	res.encoding = 'utf-8'

is probably obsolete. A response object seems to get a default encoding of utf-8 if no charset is given.
(noticed in #119 (comment))

This code was probably obsolete before but coverall seems to have a problem with it now due the algoritm used to calculate the coverage.

The obsolete code can be removed, I'm not not sure about the test. I might be safe to keep it.

@koenedaele @Wim-De-Clercq your opinions?

[Wim-De-Clercq]

The coverage check is only broken for this 1 commit, next commit would be fine. This can be safely ignored.

As for the encoding, a JSON response does not receive a charset in the header because it is technically illegal for application/json to have one.

Setting the encoding should be unnecessary. See more at Pylons/pyramid#2860 and the links there.
tldr; it would be illegal to encode a json response in something else than utf-8, 16 or 32.

And the requests library knows this

        if not self.encoding and self.content and len(self.content) > 3:
            # No encoding set. JSON RFC 4627 section 3 states we should expect
            # UTF-8, -16 or -32. Detect which one to use; If the detection or
            # decoding fails, fall back to `self.text` (using charset_normalizer to make
            # a best guess).

The encoding parameter we set would give a slight speedboost because requests doesn't have to go decide between utf 8, 16, or 32. But it's probably total overkill for us to do so.

I'm all for removing it.

[koenedaele]

Looking at that code, in other projects we retry requests a few times before giving up. Would it be useful to do the same here?

[Wim-De-Clercq]

Yea I don't see why not.