Fix bible-api.com CORS issues

[tjcouch-sil]

Sometimes when hitting the bible-api.com endpoint, we get CORS issues.

TJ:

I think it is possible that the owner of the api added throttling to his api, and we are hitting that throttle limit. We may want to reach out to the owner of the api to discuss the situation with him, just stop using the api (maybe @lyonsil could implement the data provider in C# instead ;) ), or temporarily host our own (seems like overkill). It may be worth discussing what we want to do moving forward.

Ira:

It could just be a throttling issue with the site we are hitting. However, the first error is a CORS issue and it would surprise me if throttling caused that (but it might). If we can demonstrate that it's just a throttling error then this issue is done. Do you have any thoughts on how we could do that? Like, do you get those errors when you are completely offline? If you do and you go back to main before this PR was merged do we still see the same errors when offline?

Hmm... as a data point, I just ran up Rolf's PR#245 and didn't see any of those errors at first. However a restart (trivial change to main.ts) produced one set of the 3 errors. A full restart of npm start produces the errors again.

Created as a result of #177

[lyonsil]

Interestingly I don't know that I've ever seen this on Linux, but I do see it in Windows. I looked at the Chrome dev extensions under "Network" to get more information. When I see the problem on Windows there is a status code of 429 (Too Many Requests).

I suspect the problem here is that the 429 isn't getting passed back properly and is incorrectly showing up as a CORS error. It looks like this has happened in other applications.

We could put some time into fixing the CORS logging so that it shows 429 instead of this issue, but the real underlying issue seems like a rate limiting issue to the website. It seems like some identification was made of Chromium apps running on Windows hitting the API a lot, and the server admin put in a block/rate limiter in that situation (or there is some smart infrastructure that made this determination through an algo on its own).

Seems like we should probably just move away from using bible-api.com and use the new USFM data provider. If there is a desire, we could also look into fixing the logging so that 429s get reported properly, too.