3rd-party persistence: Backup and primary partitions data differ after a single IgniteCache.get that loaded data from the persistent store which breaks skipStore and Ignite JDBC behavior

1) run 2 ignite servers on different machines
(this is important because of org.apache.ignite.internal.processors.cache.GridCacheContext#selectAffinityNodeBalanced - it takes into account MACs)

the cache under test should be partitioned with backups = 1.

2) run cassandra and insert some records into cassandra

3) connect to the ignite cluster as Ignite client node and invoke
IgniteCache.get(pk);
for the existing pk. This will load data into caches.

4) execute IgniteCache.withSkipStore().get(pk) several times
The values returned will be randomly NULLs or non-NULLs.

5) depending on a chance, the data loaded in 3) can appear in primary partition or backup partition. If they are in backup partition, then they are not visible to Ignite JDBC.

Various techniques with ignite.affinity.mapKeyToPrimaryAndBackups and

ignite.compute.call(() -> { cache.localPeek })

prove that either backup partition or primary partition does not contain data after p. 3).

However, cache.loadCache(null) loads all the data in both primary and backup partitions.

Self describing demo code added: PrimaryBackupTest.java :
1) create nodes with different MACs
2) create a test cache <Integer,Integer> with a number of backup partitions
3) implicitely load several keys, making sure we found all the keys that have at least one empty partition after implicit load.
4) test other partterns of putting keys
5) test SQL and gets with skip store for implicitely loaded keys, making sure that both nulls and not nulls are returned.