Infinite pixel sizes

[dominikl]

Prevents that Length objects with infinite or nan value are returned from getPixelSize methods.
This can cause problems downstream (e.g in Insight).
See https://www.openmicroscopy.org/qa2/qa/feedback/27688/ or https://trello.com/c/X5egtRjc/3-iviewer-fails-to-load-images-with-pixel-size-nan-or-inf

Test: Expand the dataset newproj1/newds1 as user-3 on eel (will crash Insight without the PR).

Original stack trace:

java.lang.NumberFormatException: Infinite or NaN
	at java.math.BigDecimal.(BigDecimal.java:895)
	at java.math.BigDecimal.(BigDecimal.java:872)
	at ome.model.units.Conversion$Sym.convert(Conversion.java:271)
	at ome.model.units.Conversion$Mul.convert(Conversion.java:189)
	at omero.model.LengthI.(LengthI.java:1449)
	at omero.model.LengthI.(LengthI.java:1467)
	at omero.gateway.model.PixelsData.getPixelSizeX(PixelsData.java:261)
	at org.openmicroscopy.shoola.agents.util.EditorUtil.transformPixelsData(EditorUtil.java:717)

[jburel]

A similar commit should be done in the Python code. (screenshot is web)

[mtbc]

Code change looks sensible.

[mtbc]

Glad I got in while eel's still running. 😃

[jburel]

cc @will-moore

[dominikl]

Unfortunately I have no idea where the respective code in the Python Blitzgateway is, which has to be adjusted.

[joshmoore]

Merging for 5.5.3. Plan is to get integration tests green before releasing.

Note: in a future round of refactorings, I could imagine wrapping this logic into a helper method.

[chris-allan]

Similar opinion on this to ome/omero-marshal#60. This applies to all floating point values across the entire model, is not something I think belongs in the gateway, and is a breaking change that should not be done in a patch release. I don't think making a single client work is justification for a fundamental API behavioural change.

The fact that the original code ignored marshaling all cases where PIXEL is the unit is already suspect.

[dominikl]

A pixel size with unit 'pixel' doesn't really make sense.

[dominikl]

I'll revert the PR and also remove catching the case where the pixel size unit is 'pixel'. I don't know for sure any more now, but I think there was reason for catching this (could imagine that new LengthI(value, unit) with pixel as unit isn't very happy).

[joshmoore]

I added the stack trace to the description of this PR. Looking at it, I think that the conversions are disallowed but we might need to introduce Inf and NaN handling since those don't need conversion. Inf/100 is still Inf (rather than null).

[chris-allan]

A pixel size with unit 'pixel' doesn't really make sense.

I agree but neither does light year or parsec either and we are not making decisions for users on the validity of using those units.