TableViewer: fix calls to hashCode of DataSetsRow

[dedeibel]

While working on a bugfix for the TableViewer I noticed a problem when the DataSetsRow was added to a Hashing collection. (For example the result of a fxRobot lookup, resulting in a Set).

The implementation of the DataSetsRow equals/hashCode seem to use to the model`s equals/hashCode which in turn uses the Lists default implementations. Those will in turn call it's children's methods, being the DataSetsRows.

Try using the original methods to see a stack overflow in the test case.

I am not sure about the best implementation of the equals/hashCode methods in this case, please see it just as a suggestion.

[wirew0rm]

Looks good, using identity based equalness should be good here with model being final and initialized with a new Instance for every TableViewer.

[codecov]

Codecov Report

Merging #343 (a8923d5) into master (aa9be37) will increase coverage by 0.01%.
The diff coverage is 50.00%.

@@            Coverage Diff             @@
##           master     #343      +/-   ##
==========================================
+ Coverage   51.77%   51.78%   +0.01%     
==========================================
  Files         394      394              
  Lines       41214    41214              
  Branches     6623     6623              
==========================================
+ Hits        21337    21344       +7     
+ Misses      18364    18358       -6     
+ Partials     1513     1512       -1     

Impacted Files	Coverage Δ
...rc/main/java/de/gsi/chart/plugins/TableViewer.java	50.12% <50.00%> (+1.80%)	⬆️
...ava/de/gsi/chart/utils/SimplePerformanceMeter.java	87.09% <0.00%> (-1.62%)	⬇️
...hart/plugins/measurements/DataSetMeasurements.java	75.77% <0.00%> (+0.34%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update aa9be37...a8923d5. Read the comment docs.

[RalphSteinhagen]

@dedeibel thanks for the PR! The identity-based comparison is also OK from my point of view. We are missing updated/custom hashCode(), equals(), and meaningful toString() functions here and there. Thus, these types of PR are much appreciated! 👍

N.B. as Obi-Wan once said: "Trust_the clang-formatter" ... and the QA checks for that matter. :-)

Do you think you could upgrade the unit-test to improve the coverage also for this modified diff code?

I am not only a fan of good unit-tests, but experience has shown that these make the code much more reliable as well as easier and more predictable to refactor or modify functionality. And as always, keep up the good work @dedeibel!