Compress buildinfo by changing how affectedFilesPendingEmit are stored

[Sheetal Nandi (sheetalkamat)]

A file is stored as just fileId if pending on "Full" emit and as [fileId] if its pending on Dts so this avoids coding BuilderFileEmitKind saving some bytes. Becasue in most cases it will be full emit pending (eg if there are errors) it is used as fileId.

[Andrew Casey (amcasey)]

I think the description basically says that, rather than emitting both a fileId and a BuilderFileEmitKind (presumably, a two-state?) we will use array-ness to encode the flag, thereby producing shorter output? And the shorter of the two encodings (non-array) will be used for the more common case (full emit)? Is that right?

[Andrew Casey (amcasey)]

If the flag can differ from file to file (is that actually the case?), then would it be even more compact to just have two lists: files pending full emit and files pending dts emit?

Edit: I found a test showing that it's possible. It's still not clear how much overhead splitting the list would have and it might regress some scenarios (e.g. the (contrived) tests), so we can probably ignore this for now.

[Andrew Casey (amcasey)]

I can't see a scenario where this is worse than the status quo, but it does make me wonder whether we should just emit a binary file.