Dynamic metadata error caching

[Cantor, Scott]

> IMO Hung dynamic metadata sources should block the requests the same
> way as hung attribute sources do. The current implementation favours configs
> with permanently faulty metadata sources instead of ones with temporary
> errors, even though the latter is more common, IMO.

My general experience is that network failures, while transitory, are not instantly corrected. Around here, they tend to last minutes if not tens of minutes. I only have my own experience to draw on.

> FWIW my tests show immediate continuation of the request if the query is
> rejected or a blocking for 5 seconds if there is no response.

You should see that once for any given IdP and then instant failure. I don't think it's currently smart enough to avoid re-checking different IdPs but I don't recall.
 
> Current implementation retries endlessly once in every 10 minutes. I
> think rate limiting makes sense but not in this magnitude.

Changing the default is a different matter, but ultimately that's up to the deployer anyway.

> I thought it was meant primarily for controlling the caching time if the
> response does not contain a cacheDuration.

If there's no cacheDuration or validUntil, it would be bounded on the upper end by the max setting. It's possible for the cacheDuration to be so low that it would bump it up the minimum, but that seems like a pretty unusual situation.

-- Scott