new versions of app_visitor_configs and app_identifier_visitor_configs

[samandmoore]

Summary

new versions of app_visitor_configs and app_identifier_visitor_configs

• introduce a new, deserialization friendly split registry format (array of splits is nicer to work with than a map of split name => registry)
• remove unsynced and context from assignments response (no longer used by clients)

these new endpoints will be used in by our newer versions of the mobile clients.

Other Information

• [x] ~should this be v3?~ went with v4 🎉
• [x] ~should we also introduce vNext endpoints using this split registry structure for all of the other split registry endpoints that are still actively in-use? i think that's /v3/builds/:timestamp/split_registry which powers the rails client and the js client~ went with not yet. we should have a v4 of the builds/.../split_registry endpoint but we don't need it yet.

/domain @Betterment/test_track_core /no-platform /cc @mseijas @ClaireDavis @btrautmann

[nanda-prbot]

@samandmoore needs to request platform review, or explicitly opt out, e.g.:

/no-platform

_{HOW TO: Request Reviewers}

[jmileham]

I like introducing a new API version (v3) if we're adding a new shape. Will be easier to shim into deserialization code in clients if all the new stuff is named V3. Also if we have high confidence about the shape we'll need for other clients, we could def cut the endpoints now so it's a smaller lift to upgrade them later (or add new clients in new languages that get to benefit from the better shape off the bat).

[jmileham]

<< domain tafn

[nanda-prbot]

@samandmoore needs to incorporate feedback from @jmileham. Bump when done.

_{HOW TO: Resolve Feedback}

[samandmoore]

I like introducing a new API version (v3) if we're adding a new shape. Will be easier to shim into deserialization code in clients if all the new stuff is named V3. Also if we have high confidence about the shape we'll need for other clients, we could def cut the endpoints now so it's a smaller lift to upgrade them later (or add new clients in new languages that get to benefit from the better shape off the bat).

we already have 1 thing in the api/v3 namespace which is a split_registry endpoint nested under builds. it’s what’s used by the current version of the rails client. and it uses a split registry format that’s newer than v2 but not the same as what i’m doing for these 2 endpoints. so does that mean we should go to v4?

i’d expect that we’d wanna have a v4 endpoint for /builds/:timestamp/split_registry for the rails client that uses this new format eventually, but i was thinking of not adding that until we wanna use it. there's no urgency to change the serialization format for the rails client since it's happily consuming the map-like approach

[samandmoore]

bump er ooooo

[nanda-prbot]

Needs @jmileham to provide domain review

When you finish a round of review, be sure to say you've finished or sign off on the PR, e.g.:

TAFN or DomainLGTM

If you're too busy to review, unclaim the PR, e.g.:

@myname >> domain

_{HOW TO: Give Feedback}

[jmileham]

Domain lgtm!