Cherry-picked from PR 380733 in our internal repository.
Some versions of Petrel do a gratuitous finalize on a newly created file. So, Petrel might benefit from this change. Ditto for other software designed the same way.
If a file opened for update has no real data bricks, then turn off track-changes mode. This forces a full rebuild on finalize. Even if the application asked for an incremental one. There would be practically no benefit for incremental mode since all non-empty bricks would need a rebuild anyway. And track-changes has quite a bit of overhead itself. Not to mention that an incremental build in this situation might not get a histogram at all.
Note that the new test just does a single readconst(). It will not spot a case where every brick is constant value but not always the same constant. That situation is so obscure that I will ignore it. It also won't catch an equally obscure case where the file used to have non-const data but has now been overwritten to become const.
The tweak is observable by the application because switching off track-changes mode might yield more accurate statistics and (in particular for const files) histogram. Which isn't really a problem. But can be viewed as surprising behavior. If the application just does a default finalize anyway then the track-changes data is ignored and the application shouldn't notice. Apart from improved performance.
Risk: More special cases mean more difficult testing.
The PR also contains a fix for a minor bug. If finalizing an open file twice (allowed but pointless and discouraged) the list of dirty bricks was not cleared after the first finalize. So the second one might do too much work.