Don't cache rejected promises

[langsamu]

Previously, when an IdP (issuer/AS) selector modal was cancelled (by the user clicking ESC or the 'cancel' button or by timeout) then subsequent invocations of the same UI were short-circuited to cancellation.

This was because in various places promises were put into Map caches even if they were rejected.

This change ensures that only results of resolved promises are cached.

[jeswr]

It would be better to remove the entry on promise rejection - so that the cache is still made use of when multiple requests are issued in parallel.

You'll then need some try/catch logic so that if a cached promise rejects you then retry.

[jeswr]

Even better would be to track all of the consumers waiting for a cached promise to resolve; and only cancel the operation if all of the consumers cancel.

[langsamu]

It would be better to remove the entry on promise rejection - so that the cache is still made use of when multiple requests are issued in parallel.

You'll then need some try/catch logic so that if a cached promise rejects you then retry.

I agree that this change might lead to more requests because parallel requests to the same URI might find an empty cache, in which case they'll invoke the undetlying operation multiple times.

But this change is intended only to fix my previous faulty implementation, where I was caching rejected promises. I think that some degradation in the caching layer for the parallel case is currently preferable to a complex 'multi-threaded' mitigation that I am not yet comfortable implementing.

I'm dropping one block of asyncronicity here because I was doing it wrong. I'd rather not replace it with another because I'm likely go wrong again.