Fallback to use nextResultKey on mount

[dxinteractive]

The RequestHock has an issue when a new RequestHock mounts and refetches using a resultKey that already has data returned for it (data that is held in the enty state store). On mount, the RequestHock was not bringing the resultKey into its own state, so it would not show existing response data, but it would use the refetching request state rather than the fetching request state. This meant that it was possible to have undefined results in a refetchingMap in cases where that data's existence should be guaranteed.

As all enty state around resultKeys is held outside of the RequestHock, then the RequestHock should essentially be a slave to that state.

Current behaviour

"A" and "B" are example resultKeys. The resultKey incidates which resultKey is being used to pull data from the enty state store.

Status	resultKey	nextResultKey	Description
nothing	-	-
fetching	-	"A"	make request
success	"A"	-
refetching	"A"	"B"	make new request
success	"B"	-
refetching	"B"	"B"	make same request
success	"B"	-

If we were to then remount the RequestHock and request the most recent resultKey again, the following would occur:

Status	resultKey	nextResultKey
refetching	- (!!!)	"B"
success	"B"	-

"!!!" marks where the resultKey is not set, but should have "B". It's known that "B" will be returned, as it has just been requested, so showing any possibly-existing response data during refetching makes sense.