Support testing alternate versions of curriculum automation API

[bjester]

❌ This issue is not open for contribution. Visit Contributing guidelines to learn about the contributing process and how to find suitable issues.

Current behavior

Currently, Studio is configured to use one backend for the curriculum automation API (Recommendations) which uses the default URL prefix /stable.

Desired behavior

When Studio is deployed to our non-production servers, it should attempt to use an unstable version of the curriculum automation API, but fallback to the stable version if it cannot connect to the unstable version. This should occur through backends that use those respective URL prefixes.

• A new backend class CompositeBackend should be created which should:
  • essentially implement the composite OOP pattern
  • accept a list of backends in its constructor
  • implement the same interface as Backend
  • choose the first backend from its list when its connect method is called, based on its Okay response
  • use the chosen backend for all other requests
• The backend factory RecommendationsBackendFactory should:
  • maintain its current implementation if Studio is in production mode (settings.SITE_ID == settings.PRODUCTION_SITE_ID)
  • otherwise create a CompositeBackend with 2 child backends, one with an /unstable URL prefix and another with the default /stable prefix (in that order)

Value add

Allows us to test improvements to the curriculum automation API on our non-production servers, prior to replacing the stable endpoint.