Prefix non-local build config names with ci/

[zanderso]

Part 1 of flutter/flutter#145263

This PR updates the names of builds outside of local_engine.json to be prefixed with the string ci/ (or ci\ on Windows). For better or worse, the "name" field of a build is used to construct a path used as the source directory of a copy operation (I think the CAS archive step?). Because of that, changing the name of a build also requires updating the build output directory of the ninja build.

This PR also adds tests to make sure the naming of these builds remains consistent.

[keyonghan]

No recipes change should be expected. LGTM for configs change.

[johnmccutchan]

I'm fine with this as a temporary measure but I'd like to understand the plan to get us into a place where there is only one definition of each build config (aka out directory).

[zanderso]

I'm fine with this as a temporary measure but I'd like to understand the plan to get us into a place where there is only one definition of each build config (aka out directory).

There are a few different ways to accomplish that that we'll need to discuss. I would like to consider approaches where the exact contents and layout of out/ is an implementation detail of et and CI, and in which human readable descriptions of the build configs provide a good guide for which config a developer needs at any time. (If you need to know the fine-grained details, that could be an et query subcommand.) As an example, if we choose to use the GN toolchain feature to build multiple configurations as part of the same ninja build as I've heard a few folks discuss, then the output for some build configurations would shift from the top-level out/ directory into a subdirectory 2-3 layers deep. The user shouldn't have to worry about that.

I think maybe the spirit of your question is not exactly about the out/ directory, though, but more about having a one-to-one mapping between configurations and names. If/when we design a configuration language for generating the .json files instead of hand-coding them, we should ensure that we get that one-to-one property by construction. But exactly how to do that, I don't have a detailed design for.