Fix FaultTolerantPartitioningScheme obtaining logic

[losipiuk]

With caching logic used when FaultTolerantPartitioningScheme was obtained it was possible to get FaultTolerantPartitioningScheme with wrongly set partition count. In cache keyed on PartitioningHandle we could store a FaultTolerantPartitioningScheme object obtained for specific partitionCount value. Later on when we asked for same handle but without specifying partitionCount we still got cached FaultTolerantPartitioningScheme.

This commit changes cache key to inclue partitionCount.

Description

Additional context and related issues

Release notes

( ) This is not user-visible or is docs only, and no release notes are required.
( ) Release notes are required. Please propose a release note for me.
(x) Release notes are required, with the following suggested text:

# Section
* Fix possible query failure for MERGE queries when `retry-policy` set to `TASK` 
  and `query.determine-partition-count-for-write-enabled` set to `true`.  ({issue}`19979`)

[findepi]

withPartitionCount became unused, remove

[findepi]

before the change, we guaranteed that "if value is taken from the cache, the partitionCount is made to be exactly as requested".
i don't know why we didn't guarantee that for new values.

maybe we could add this

if (partitionCount.isPresent()) {
  verify(result.getPartitionCount() == partitionCount.get(), "...");
}

however, create doesn't seem to guarantee this property -- return new FaultTolerantPartitioningScheme(1, ....

Thus this PR (1) fixes caching logic
and introduces a pretty subtle side-effect (maybe correct). If this side effect is intentional, it would be good to call it out (perhaps as separate commit)

[losipiuk]

I am pretty sure this method should not be called with non-empty partition count for case when create would return scheme with partitionCount == 1.
verify seems like a good change.

[findepi]

move below create, maybe bottom of the class

[findepi]

a data provider would produce much more readable failure messages
otherwise when inspecting CI error message you need to hope the line numbers didn't change between CI and your local copy

out of scope for this pr