drop null from SharedFlagsSettings properties

[brendankenny]

Several SharedFlagsSettings are arrays but are both optional and nullable for historical reasons. We should drop null as a possible value.

I believe they should all be compatible with this change (an empty array would become the replacement null state, and we'd have to check .length instead of just falsiness), though this will require some fixes in config.js and gather-runner.js.

Original motivation was to clean up for representation in proto form, but it's also just excessive complexity when trying to understand allowed flag values.

Affected properties are blockedUrlPatterns, additionalTraceCategories, onlyAudits, onlyCategories, skipAudits, extraHeaders, and precomputedLanternData.

[patrickhulce]

I think it's teensy bit problematic in some of the cases to use [] for them (like only audits, I can see it being misunderstood to mean run no audits, but then again what on earth would you expect to happen in that case, so seems fine 👍 )

What is your thinking on the replacement null value for precomputedLanternData? that's the only one I see here where [] or {} doesn't really work

[brendankenny]

What is your thinking on the replacement null value for precomputedLanternData?

we can ask @exterkamp, but I may have spoken too soon on that one and extraHeaders. I think the main concern was repeated fields, and they aren't an array.

like only audits, I can see it being misunderstood to mean run no audits, but then again what on earth would you expect to happen in that case

yeah, I see both sides too. I feel like there is a way to express what we mean here that also keeps proto lists and default values happy.

With less of a need for proto config settings, though, maybe this is a v6 breaking change. We probably have enough decisions still to make on our plate

[brendankenny]

we could clean some of these up, but nothing is falling over from these excess nulls, and the proto move we thought we were going to make for settings isn't going to happen, so I'm going to close this issue. We can revisit if someday something forces us to care :)