Allow for correction of dynamic css transformations

[alexhartstone]

Recently a bug with interactions on css-transformed plots was fixed. However, this fix is not yet dynamic, and doesn't work in the use-case where transforms are being applied dynamically - for instance, to simulate zooming of a plot.

This codepen demonstrates a statically applied transform, applied before, showing the fix working nicely.

This codepen demonstrates a dynamic css transform, applied after plot creation, imitating a zoom in some kind of app - note the hover label position is incorrect for anything other than a fully zoomed-in plot.

The inverse transform matrix that allows this fix to work is stored at plot creation in the _fullLayout property. This issue is to add some kind of update call to the the api to allow for recalculation of this matrix.

[alexhartstone]

@archmoj @alexcjohnson FYI - the follow-up issue

[alexcjohnson]

Thanks @alexhartstone

What about this as a strategy: the thing we want to avoid is walking the tree and recreating the transformation matrix on every hover. But at the beginning of a hover event we're already making getBoundingClientRect calls so another such call should be cheap. So how about we not even calculate the transformation during the initial draw, but when we're ready to ask for the transformation, check whether we have one already and whether the bounding box of the entire gd is the same as it was when that was calculated - and recalculate the transformation if either of those is not the case.

Seem reasonable? This way there's nothing active the user needs to do, it'll just work. If the graph is zooming during the hover event the hover won't catch up to this until the mouse moves, but that may actually be for the best.

@alexhartstone would you be interested in trying this out and kicking off another PR?

[alexhartstone]

@alexcjohnson that sounds great, I will get on this ASAP - most likely monday australian time (~48 hrs). Thanks for the prompt response!

[archmoj]

Fixed by #5302.