I randomly sampled 10 dogfood config files.  Here's how they break down:

5 simple configs with one full-traffic group; this file wouldn't be necessary if we had this default setting
4 configs that would remain necessary because the group has parameters set in addition to features
1 config that would remain necessary because it sets forcing flags

Cutting down half the dogfood configs seems worthwhile to me for such a simple change.

CC asvitkine, as part of our plans to make experiment rollouts easier.

Seems reasonable to me. I'll add it to the deficiencies doc.

It's a little unfortunate that to support this, we'd need to put the concept of dogfood all the way into base/ but I agree that benefits probably are worth it.

In terms of how this could work, it would need some API on base::FeatureList during its setup that could set dogfood mode, which would then return those features as enabled.

So VariationsService could be responsible for setting that. We'd need to decide whether we'd want to add a new bit to the proto just for that, or re-use a special study for this, which would mean hardcoding the name of a study into Chrome. (We can't use Feature API since it won't be initialized yet since we're trying to initialize it.)

Assigning to myself for now. Thanks for the idea!