compose.yaml: autopair first-party leader

[tgeoghegan]

To enable the demo workflow, users will need to pair two aggregators with the control plane. Further, one of them must be first-party, which can only be done using a CLI built with feature admin. But the one we distribute via GitHub releases isn't, and I argue it shouldn't be, which means that demo users can't appropriately pair aggregators.

We could provide a curl or wget command that'd do it, but as it turns out, we already bundle the divviup CLI in the divviup_api container, so let's just use that, since the API URL and token for the aggregators are static!

I'm thinking we should have the demo user pair the other aggregator themselves with divviup to simulate what they might have to do in a realistic use case, if they bring their own helper.

This commit:

• adds feature admin to builds of divviup_api_integration_test in docker-release.yaml so that the bundled CLI will have --first-party and --shared
• adds a service pair_aggregator to compose.yaml that uses the /divviup entrypoint to pair janus_1_aggregator as a first-party, shared aggregator
• adds a stanza for pair_aggregator to compose.dev.override.yaml
• makes compose.dev.override.yaml build all images with features integration_test,admin

Part of #1096

[tgeoghegan]

Would be nice to not duplicate these constants but YAML 🤷🏻

[tgeoghegan]

The compose test is failing, because it uses divviup_api_integration_test:0.3.12, which was not built with feature admin, so divviup aggregator create fails. I'll have to break this into a couple changes: first add the feature flag to docker-release.yml, then cut a release, then bump to that version in compose.yaml and add the pair_aggregator service. I will juggle those PRs tomorrow.

[branlwyd]

This PR looks good in terms of functionality.

I'm thinking we should have the demo user pair the other aggregator themselves with divviup to simulate what they might have to do in a realistic use case, if they bring their own helper.

I think it would be nice to have the system preconfigured -- i.e. all aggregators paired -- to make it as easy as possible for folks to get up & running. Our demo script can call out that this will be a required step in a real deployment, maybe eventually linking out to documentation describing how the pairing is done.

I'd even go so far as to say we should create a preconfigured task, maybe providing a client config that makes it easy to start submitting data. Though that might be inflexible if e.g. the user wants to play around with a different VDAF.

[tgeoghegan]

#1100 adds the build flags.

I think it would be nice to have the system preconfigured -- i.e. all aggregators paired -- to make it as easy as possible for folks to get up & running. Our demo script can call out that this will be a required step in a real deployment, maybe eventually linking out to documentation describing how the pairing is done.

Sure!

I'd even go so far as to say we should create a preconfigured task, maybe providing a client config that makes it easy to start submitting data. Though that might be inflexible if e.g. the user wants to play around with a different VDAF.

I prefer making them create the task. If we preload one, its ID will be random anyway, so they'll have to do a divviup task list which is barely any easier than divviup task create. Plus, creating the task themselves then makes it obvious how they could tweak the divviup task create to do things like create a different histogram.