Add in a fallback API call for the Folio driver getModuleMajorVersion function

[meganschanz]

This is a possible work around for the issue with submitting requests (placeHold) as of the Sunflower release in FOLIO which fails due to permission errors in the getModuleMajorVersion function when calling the /_/proxy/tenants/ API endpoint. Ideally we won't need to merge this and can discover some additional permission we just need to grant our application user (and document it in the wiki), since it isn't great that this method means we always have to try the first call to see if it fails before making the one that will work after Sunflower.

[meganschanz]

I still plan on trying the original API call with an admin account, but our FOLIO user account administrator is still working out the kinks in their process for managing permissions in Sunflower so I'm not able to do that quite yet.

[demiankatz]

Thanks, @meganschanz. A few thoughts:

1.) As you've probably seen, it's been reported on Slack that an admin account can retrieve the necessary information, so there probably is a permission we can add to get around the problem.

2.) A separate question is whether the "old" method is going to be deprecated in favor of the "new" method -- so maybe your work is worth keeping in some form even if there's a simpler solution.

3.) I also wonder, if we're going to keep this logic, whether we also need to cover the case where the first call does not return JSON at all. I think we might want to hit the fallback not just when the JSON contains errors but also if the return value cannot be parsed as JSON.

[meganschanz]

2.) A separate question is whether the "old" method is going to be deprecated in favor of the "new" method -- so maybe your work is worth keeping in some form even if there's a simpler solution.

With that in mind, I've added more failure codes to allowed to pass through to the fallback method (400 for a bad request, 404 for when the route isn't valid and really is removed, 500 for FOLIO server errors).

3.) I also wonder, if we're going to keep this logic, whether we also need to cover the case where the first call does not return JSON at all. I think we might want to hit the fallback not just when the JSON contains errors but also if the return value cannot be parsed as JSON.

Good point. I've updated it to handle if we don't get valid JSON back at all and added some unit tests for the fallback scenario.