[refactor] Rename OperatorState to ValueState, add ListState

[aljoscha]

ValueState behaves exactly the same as OperatorState. ListState is a
stateful list to which elements can be added and for which the elements
that it contains can be obtained. To create a ValueState the user
passes a ValueStateIdentifier to
StreamingRuntimeContext.getPartitionedState() while they would pass a
ListStateIdentifier to the same function to retrieve a ListState.

This change is necessary to give the system more information about the
nature of the operator state. We want this to be able to do incremental
snapshots. This would not be possible, for example, if the user had a
List as a state. Inside OperatorState this list would be opaque and
Flink could not create good incremental snapshots.

This also refactors the StateBackend. Before, the logic for partitioned
state was spread out over StreamingRuntimeContext,
AbstractStreamOperator and StateBackend. Now it is consolidated in
StateBackend.

[aljoscha]

This does not touch the documentation yet. I would adapt it once we come to the consensus that we want these refactorings.

[gyfora]

This contains a lot of changes that conflict with #1305 , I think we should come to agreement on that and merge that first.

[aljoscha]

@gyfora yes, I'm aware of that 😄

[gyfora]

I am wondering whether in this form the ListState is a useful abstraction to have.

It has a very forgiving definition of a list: It only supports adding values (ever growing) and no removing or any other List operation that I think would be just as common.

Also I think other collection types such as Sets and Maps are similarly common and those are not covered by this.

Maybe a better approach would be to make a very generic collection state type that supports all the different operations which could then be used to implement ListState, SetState, MapState etc.

[aljoscha]

Yes, this is only the starting point. As it is now, this should make it very easy to add other types of state.

[gyfora]

I see the point of refactoring, what I am saying is that I wouldn't add this ListState implementation to the API because it's not very useful to have. As a user I would expect the normal list operations on the list state.

[aljoscha]

I limited the interface on purpose. I think for most purposes it should be sufficient and having it in this limited form allows us to to incremental checkpoints very easily. If we only allow adding elements and clearing the whole state you immediately know, for example, what you have to checkpoint if you do an incremental checkpoint. If we allow arbitrary modifications of the list state we loose that or need to use work-arounds. (I think for that case users would have to use a ValueState that contains a List, for example.)

[aljoscha]

Closing for now, I have a bigger PR coming up