Show information gain in header validator output

[apasel422]

We also change the command-line output to resemble that of the event-level reports by using randomized trigger rate instead of flip probability and decimals instead of percentages.

[csharrison]

Open questions:

1. Should we retain the flip percent terminology from the command-line tool?
2. Should we show the value as a percentage or decimal in [0, 1]?

For both of these I would argue we should make the output resemble that of the event-level reports, and go with randomized_trigger_rate and [0, 1]. But regardless, we should probably be consistent in the command-line output and the header validator output.

This all seems fine. We can update the command line output to align.

[csharrison]

Otherwise the PR LG

[apasel422]

Open questions:

1. Should we retain the flip percent terminology from the command-line tool?
2. Should we show the value as a percentage or decimal in [0, 1]?

For both of these I would argue we should make the output resemble that of the event-level reports, and go with randomized_trigger_rate and [0, 1]. But regardless, we should probably be consistent in the command-line output and the header validator output.

This all seems fine. We can update the command line output to align.

Ack. I think we'll need to use at least toFixed(5) for the decimal change in order for the default event rate to show up as non-zero. Do you think we should go beyond even 5?

[csharrison]

Can we match the impl which limits to 7 digits of precision after the decimal point?

[apasel422]

Can we match the impl which limits to 7 digits of precision after the decimal point?

Done.