[FLINK-32410] Allocate hash-based collections with sufficient capacity for expected size

[StefanRRichter]

What is the purpose of the change

The JDK API to create hash-based collections for a certain capacity is arguably misleading because it doesn't size the collections to "hold a specific number of items" like you'd expect it would. Instead it sizes it to hold "load-factor%" of the specified number.

For the common pattern to allocate a hash-based collection with the size of expected elements to avoid rehashes, this means that a rehash is essentially guaranteed.

This PR replaces constructor calls for allocations for expected size with helper methods (similar to Guava's Maps.newHashMapWithExpectedSize(int)) .

Verifying this change

This change is already covered by existing tests.

Does this pull request potentially affect one of the following parts:

• Dependencies (does it add or upgrade a dependency): (no)
• The public API, i.e., is any changed class annotated with @Public(Evolving): (no)
• The serializers: (no)
• The runtime per-record code paths (performance sensitive): (don't know)
• Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: (no)
• The S3 file system connector: (no)

Documentation

• Does this pull request introduce a new feature? (no)
• If yes, how is the feature documented? (not applicable)

[flinkbot]

CI report:

• 5bc1273 Azure: SUCCESS

Bot commands

The @flinkbot bot supports the following commands:

• @flinkbot run azure re-run the last Azure build

[pnowojski]

LGTM assuming green build/no conflicts