[FLINK-34558][state] Support tracking state size

[hejufang]

What is the purpose of the change

Support tracking state key size and value size and reporting related metrics by metrics reporter.

Brief change log

Add key /value size statistics when accessing state. 
Add configurations to control whether this feature is enabled (disabled by default) and configure the sampling rate.

Verifying this change

This change added tests and can be verified as follows:
MetricsTrackingValueStateTest
MetricsTrackingMapStateTest
MetricsTrackingListStateTest
MetricsTrackingReducingStateTest
MetricsTrackingAggregatingStateTest

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): yes
• 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? yes
• If yes, how is the feature documented? not documented

[flinkbot]

CI report:

• f1b1bf0 Azure: SUCCESS

Bot commands

The @flinkbot bot supports the following commands:

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

[Zakelly]

Thanks for the PR! In general I have a question: why serializing the key/value by sampling, instead of read the serialization result/length of current put/add, especially for RocksDB? WDYT @masteryhx

[Zakelly]

Please use state.size-track as prefix.

[Zakelly]

Please change the description accordingly.

[Zakelly]

It seems the LatencyTrackingStateFactory is still used, why this is not renamed?

[hejufang]

Thanks for the PR! In general I have a question: why serializing the key/value by sampling, instead of read the serialization result/length of current put/add, especially for RocksDB? WDYT @masteryhx

@Zakelly In my opinion, serializing the key/value by sampling has the following reasons:

1. Unlike state access latency, the size of key/value cannot be simply obtained in the outer MetricsTrackingState. For example, in RocksDBValueState#value valueBytes.length can only be accessed within the method
2. Serializing the key/value by sampling can also collect statistics on other types of statebackend, not only for RocksDB