fix(OCMDiscoveryService): Also cache error results during discovery

[provokateurin]

Summary

On my personal instance I'm currently facing the problem that a folder shared from another instance is no longer available, as the server went down. Unfortunately the remote server doesn't terminate the connection instantly, but it only gets stopped by the client timeout.
This makes literally every request to my own Nextcloud server 10 seconds longer, as the timeout happens every time.

Decreasing the timeout would help a little bit, but then in other scenarios it might also lead to unintended consequences, so it isn't a good way to workaround the problem.
When the remote server has a problem we must also cache the result, but for a much shorter duration (e.g. 1h), just to prevent that every request tries to contact the remote server again.
Now we still check once in a while if the server is still there, but not on every request that uses the Filesystem which was slowing down everything dramatically.

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)

[provokateurin]

/backport to stable30

[provokateurin]

/backport to stable29

[provokateurin]

/backport to stable28

[ArtificialOwl]

not a huge fan of caching for so long, might be interesting (and not too much of overkill) to have a background process that check the status of faulty remote instance on its own and reset faulty cache on success

[provokateurin]

I can also reduce the error caching to 5m or even lower, but we need to prevent that this request occurs on every request which can lead to this kind of self DOS.

[skjnldsv]

I now experienced the opposite. WHile working on that area, I got one of my instance pending an update. So returning a 503.
I couldn't understand why this was still throwing despite me having done the update.

I think some errors should be left out from caching.

[provokateurin]

True, maybe it could be more precise. But the previous behavior was also completely unacceptable for end-users with the entire instance being super slow on every request.