Control arrangement merging with default_exert_logic

[teskje]

Add an alternative merging strategy for arrangements.

Up to this point, we could either not merge arrangements outside of ingesting updates, or always keep them in the most compacted form by specifying idle_merge_effort. Since TimelyDataflow/differential-dataflow#411 landed, Differential offers to replace the whole exertion logic, which we conditionally do with this PR. When the idle merge effort is 0, we honor an alternative setting of default_arrangement_exert_proprotionality that specifies which batches in an arrangement should be merged. Specifically, the proportionality determines when to merge the largest with the next largest batch.

Motivation

• Fixes a known bug

Advanced MaterializeInc/database-issues#4918

Checklist

• This PR has adequate test coverage / QA involvement has been duly considered.
• This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design.
• If this PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way), then it is tagged with a T-proto label.
• If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label (example).
• This PR includes the following user-facing behavior changes:

[shepherdlybot]

This PR has higher risk. Make sure to carefully review the file hotspots. In addition to having this change reviewed, adequate tests should be considered and it may be useful to add observability and/or a feature flag. What's This?

Risk Score	Probability	Buggy File Hotspots
🔴 81 / 100	61%	2

Buggy File Hotspots:

File	Percentile
../session/vars.rs	100
../src/coord.rs	99

[umanwizard]

The idea sounds fine, but I can't actually evaluate what this does without reading the internals of Differential