Integrate with OSM Teams using a feature flag

[modulitos]

Addresses: https://github.com/mapbox/osmcha-frontend/issues/390

This branch introduces the ability to fetch teams from the OSM Teams service instead of the OSMCha endpoint. This is controllable using a feature flag in the /src/config/index.js file. This PR should not cause any changes to the production website, because the feature flag is set to false by default.

I figured that a feature flag was the simplest and safest way to eventually migrating all team data to OSM Teams. Although here are all of the options I considered:

1. Choosing a service via feature flag Keep the feature flag, but refactor it behind an environment variable or command line arg.

Non-goal, but worth considering in the future, is to make the feature flag configurable by the user (eg: via a menu checkbox option or directly in the js console)

PROS:

• When the flag is disabled, it won't affect the behavior of the production app. This allows for incremental development because we can gradually merge in the feature.
• We avoid the complexity of merging the data. For example, an alias like yarn run osm-teams will start the app with the osm-teams feature flag enabled.

CONS:

• The teams will be fetched from either OSMCha or osm-teams. There is no in-between, which means we'd have to migrate the teams from OSMCha into osm-teams when we ship.

2. Implicitly merging the teams from both services We can have the client fetch teams from both OSMCha and osm-teams, and merge them on the client as well. If we do this, however, we will need to answer some questions about merging teams. For example, are we going to have teams with the same id's on both services? If so, how will we handle the merge? And for how long do we want to persist teams from both endpoints?

3. Explicitly selecting the teams from both services Add an extra UI widget that will allow the user to choose teams from OSMCha or osm-teams explicitely.

PROS

• users can mix and match teams from OSMCha and osm-teams
• we wouldn't have to migrate the teams from OSMCha into osm-teams

CONS

• Extra UI development effort to build out a separate picker
• Allowing users to explicitly choose either team will affect the UX. Will users know the difference between OSMCha and osm-teams?
• We'll have to be careful about not having conflicting teams between OSMCha and osm-teams. For example, if a team from OSMCha has the same id as a team from osm-teams, it could cause problems.

I think I would favor option 1 because it would allow incremental development, and once we feel that osm-teams is ready, we can enable the feature flag by default or remove it entirely. Also, it seems like the goal is to replace OSMCha's team service entirely with the osm-teams service, and not support the ability to use both services simultaneously. But of course, I'm lacking some context and there might be some use cases that I'm missing.

Let me know if there are any thoughts 👍

---

TODO's:

• [x] transform the data the comes back from osm-teams endpoint to match the existing OSMCha model so that the filters are actually working
• [x] fix network requests to only query the osm-teams api when a team is selected
• [ ] test the exclude_teams and exclude_trusted_teams filters to make sure they are working with the OSM Teams service. I suspect they will need to be updated to leverage the new filter types.

[batpad]

Just quick thoughts:

@modulitos - I'd favour keeping it simple and having an environment variable turn this feature on / off for now. It seems like as is it would allow other developers and users to try it out and see how using the OSM Teams API for this would work for the end-user.

@willemarcel - it would be great to get your initial thoughts on this -- do you think it's a better idea to have a flag to use OSM-teams or OSMCha, or let users filter by either? I do think it would be really nice if we could incrementally move toward letting teams management happen in OSM-Teams and OSMCha handle the search and filter. Not sure if this seems reasonable / what you think it might take to get us there?