Replaced Window Update Check by 'versioning' (previously used 'hashing')

[da-h]

Description

This PR

• removes the variable consistent_pane_copy from js/main.js
• api-change: implements version-numbers for window content, s.t. a client knows if it is up-to-date or needs to re-request the window content
• api-change: removes the api endpoint /win_hash (as it is not used anymore in the project)
• additionally, moves the pane-update to the processPane method. this is required to save some requests where the whole window content would have be resent (see notes below).

Motivation and Context

(See discussion below).

How Has This Been Tested?

(Just the cypress tests).

Types of changes

• [ ] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
• [x] Code refactor or cleanup (changes to existing code for improved readability or performance)

Checklist:

• [ ] I adapted the version number under py/visdom/VERSION according to Semantic Versioning
• [x] My code follows the code style of this project.
• [ ] My change requires a change to the documentation.
• [ ] I have updated the documentation accordingly.

[da-h]

~That's interesting: the variable seems to be required for react 17 (tests are failing now). However, I've tested it on react 16 successfully without any errors. As 18 gives some very good changes, like automatic batched processing, I'll suggest to look into this PR once/if visdom runs under react 18.~

It seems there is a bug in the ImagePane or its test, introduced by combining #900 and #902.

[da-h]

With #908 in-place, this PR succeeds all tests now & is thus now ready for review.

[da-h]

I see!! I would have not thought about this. Thanks for clarifying. :+1:

I'll update this the next days to your proposed solution.

[da-h]

I've just implemented the window-message versioning, to replace consistent_pane_copy. With the background-information of how this mechanism worked, I now also understood the reason for the setTimeout inside of the _checkWindow (now called updateWindow) function:

• in case a pane-update is found for a pane that is not yet processed, we wait for some time until the update can be applied
• then, if the time passes and no such pane is found, we (re-)request the pane using postForEnv
• this, however can lead to wrong orders of window updates: imagine there are two updates waiting for a pane to be saved in storeData using such timers, say update1 and update2 (that builds upon the changes in update1). In case the pane is saved, just when update1 is re-queued using a new timer and update2 checks for the existence of the pane, which is now given, the changed patch could lead to a wrong state, or possibly even to an error.

Using the idea of specifying the version of each pane state, we can circumvent the timers:

• we move the actual update to the processPane-function and remember the last version that we know is waiting to be processed
• if a new update comes in, we first check if the pane exists in storeData and matches our expectation of the previous version. Or, If it does not exist or the version does not match, we check also if there is a update waiting to be processed, with our expected version of the pane state.
• In total, I expect this implementation to be a bit snappier.

[da-h]

Just to be sure: This PR does change the server-client-api by replacing the requirement of hashing the window contents. Also, this PR removes the win_hash endpoint.

Personally I think, since this will be part of 1.0.0, incompatible api-changes should be ok to occur(?) Especially, as the new implementation ~should work~ works with older saved environments, i.e. backwards-compatibility is at least data-wise ensured.