Add CLI flag to retry HTTP requests

[s2b]

Due to implementation details in certain hosting setups, there can be a delay between creating the temporary cachetool file and it being accessible via HTTP. To address this, both FileGetContents and SymfonyHTTP clients are extended to retry HTTP requests on failure. By default, that new configuration option is set to 3, which should cover most cases. However, its value can also be adjusted via CLI (--web-retry) or config file (webRetry).

The test setup is extended to cover both successful and failed retries. In the test setup, the availability delay of the php server is used to cover the mentioned test cases.

Resolves #209

[gordalina]

I think it would be a better fit to do the retry logic at the application level, not at the adapter. We could then use the --retry global argument, if the adapter returns an error then we can do the retry.

What do you think?

[s2b]

I see your point. The only disadvantage would be that the Symfony implementation couldn't be used then.

[gordalina]

I'm sorry, I wasn't very clear. When I said Application, i mean in src/CacheTool.php in the __call function.

[s2b]

Can you explain why that location is better? From my point of view, this feature is only related to the web-based workflow and isn't relevant for CLI. So if it should be implemented "higher up" in the code, my next choice would be src/Adapter/Web.php.

However, this would still mean that we couldn't make use of Symfony's more sophisticated implementation of retries in RetryableHttpClient. However, if you prefer that approach, that's fine by me and I'll adjust the PR.

[gordalina]

This is something that also happens with fastcgi, so doing it at the cachetool layer would address both issues. See #199

[s2b]

Maybe I'm missing something here, but I don't think that this is possible without some major refactoring of the adapters.

As far as I can see, the adapters behave quite differently when errors occur. Sometimes, RuntimeException is thrown, sometimes a serialized string is returned (which contains an error key to differentiate errors from other output) and sometimes only a string is returned (where it wouldn't be possible to differentiate between error and other output).

Maybe it makes sense to rename the config option to retry, but to leave the implementation in the adapter layer?