Add ConfigLoader with deduplicated logging and try_examples config caching

[agriyakhetarpal]

Description

• This PR introduces a caching mechanism where the requests to load the try_examples.json configuration file are deduplicated, and the tryExamplesConfigLoaded flag is preserved but managed more carefully.
• A configLoadPromise has been introduced to handle concurrent requests with a basic cache that prevents multiple retries and prevents console noise.

Closes #240

Additional context

In light of scikit-image/scikit-image#7644 where this problem was first noticed.

[agriyakhetarpal]

I hope this is in line with what you had in mind, @Carreau! :)

I used a local scikit-image docs build to test it out on a page with thirty TryExamples buttons; here's a screen recording:

Screen.Recording.2025-01-10.at.7.45.16.AM.mp4

To compare with the previous functionality, this deployment: https://output.circle-artifacts.com/output/job/048f37f1-2a97-4826-b310-3c66a77deb9c/artifacts/0/doc/build/html/api/skimage.feature.html generates thirty errors, one per button.

[agriyakhetarpal]

Thanks, @Carreau, yes, it makes sense to just remove the throttling. I did it based only on your suggestion, but it feels redundant, especially since we have just one configuration file per iframe/component.

I'll remove the configLoadPromise = null to keep the promise cached.

[Carreau]

Looks good to me – but again I'm not a JS expert.

[gabalafou]

I was asked to review this pull request last week.

It's nice to see the inefficiency of making several concurrent network requests for the same data being addressed here, so thank you!

The changes introduced in this pull request look good to me, however I do have a couple questions and one concern.

I wasn't able to dive deep into issue #240, but one thing that immediately jumped out at me in that issue's description was:

I assume this happens because we run the JavaScript file per iframe

I just want to be clear that if this JavaScript file is getting loaded into multiple iframes on the same page, this PR will not prevent multiple network requests.

Another thing that caught my attention was the use of the word "retry" in the PR description and in the linked issue. As far as I can tell, there is no retry happening anywhere. To me the word retry means an intentional re-request when you know that the first request failed. I see no logic anywhere in this codebase that does that. I suspect that the word was meant in a different way, but because I'm not super familiar with the issue at hand, I'm bringing it up because I want to make sure I'm not missing something.

These questions bring me to my one big concern which is the lack of tests. In my mind, this is quite a bit of logic to leave untested. Furthermore, tests could go a long way to clarifying intent. For example, if these changes were intended to work across iframes, a good test case would show it working across multiple iframes.

Since the code has already been approved, I am not going to request changes, but lack of tests really worries me for long-term maintainability.