… tests should fail if exception isn't thrown

This commit strengthens tests in StateBackendMigrationTestBase that
depend on a certain state operation (restoring state, accessing state,
etc.) to be failing to assert correct behaviour. However, we previously
do not really fail the test if no exception was thrown when there should
be.

This also caught some bugs in the test itself which had the tests
verifying incorrect behaviour.

…ackend should always be compatible

Previously, we were only checking if the new namespace serializer is
incompatible, while properly we should be checking that it is strictly
compatible.

This doesn't affect any user expected behaviour, since the namespace
serializer is never exposed to users.

…ore understandable

The StateBackendMigrationTestBase previously mocked user behaviour of
upgrading serializers by using a single serializer class, that can be
configured with different target compatibility results when they are
checked for compatibility.

This is a bit hard to understand, also doesn't really reflect how a user
would actually approach the feature. Instead, instead of configuring a
single serializer class with different compatibility "personalities",
this commit uses actual different classes, V1TestTypeSerializer,
V2TestTypeSerializer, and IncompatibleTestTypeSerializer, to simulate
the compatibility cases in tests.

This commit also refactors the serializer migration related test
serializers / types / snapshots to the testutil package, so that it can
be shared by other state migration related tests in the future.

A StateSerializerProvider  wraps logic on how to obtain
serializers for registered state, either with the previous
schema of state in checkpoints or the current schema of state.

…in RocksDBKeyedStateBackend

This ensures that all restored state, even non-accessed ones after the
restore, have a meta info available on future snapshots.

…erProviders

This commit lets all state meta info subclasses use
StateSerializerProviders to replace direct serializer instances. This
allows meta infos that were instantiate with restored serializer
snapshots to not eagerly access the restore serializer when restoring
state. This needs to be avoided since when restoring from 1.6, the
restore serializer might not be available; for RocksDB, this should be
tolerable.

This further coherents with the principle of not accessing the restore
serializer unless neccessary.

… map from RocksDBKeyedStateBackend

With the fact that now restored serializer snapshots are held by their
eagerly created meta infos in the kvStateInformation map, we no longer
need to keep a separate map of restored meta info snapshots. As can be
seen in the changes, that map is no longer queried anywhere.

…apKeyedStateBackend

Likewise in the RocksDBKeyedStateBackend, since restored snapshots are
now part of the registered meta info map, we no longer need this map.
This commit also reflects the principal changes we made to the
RegisteredKeyValueStateMetaInfo class in the HeapKeyedStatBackend.

…faultOperatorStateBackend

Likewise in the RocksDBKeyedStateBackend, since restored snapshots
are now part of the registered meta info map, we no longer need these
maps. This commit also reflects the principal changes we made to the
RegisteredKeyValueStateMetaInfo class in the DefaultOperatorStateBackend.

…cessed restored state

…izer(...) from StateMetaInfoSnapshot

That method is no longer used after the series of changes in
FLINK-11094. This also corresponds to the new principle that the restore
serializer is only accessed, when the state backends attempt request it
from their state meta infos. We do not create restore serializers
eagerly when creating meta infos from a StateMetaInfoSnapshot.

…alizer snapshot in StateMetaInfoSnapshot

This corresponds to the abstraction rework of retiring
TypeSerializerConfigSnapshot to be replaced by TypeSerializerSnapshot.
The related fields / methods should not mention "config" anymore.