More splitting

So far, we've split out of our monolith everything related to background tasks, and we've added a few HTTP API views for the new microservices to interact with the main application.

Since the new API allows us to add runs, there's another part we can split out of the monolith--the Training feature.

This feature can run on its own as long as it's able to generate new runs. When a user wants to start a new training plan, the main app can interact with the Training microservice and ask it to generate new runs.

Alternatively, the design could be reversed for better data isolation: the Training microservice publishes an API that returns a list of runs with their specific structure, exactly like the Strava API that returns activities. The main Flask app can then convert them into Runnerly runs. The Training plan can work without any specific knowledge about the Runnerly users: it gets asked to generate a plan given a few params.

But doing this new split should happen for a good reason...