XMLMockObjects: make artificial SHA1 schema-compliant

[melissalinkert]

See ome/bioformats#3810

[sbesson]

To my original surprise, this change failed the unit tests in https://merge-ci.openmicroscopy.org/jenkins/job/BIOFORMATS-image/1151 with the following validation error

2022-04-18 00:17:05,448 [main] ERROR loci.common.xml.XMLTools - cvc-length-valid: Value '1234567890ABCDEF1234' with length = '10' is not facet-valid with respect to length '20' for type 'Hex40'.
2022-04-18 00:17:05,449 [main] ERROR loci.common.xml.XMLTools - cvc-type.3.1.3: The value '1234567890ABCDEF1234' of element 'HashSHA1' is not valid.

After some investigation, I suspect the explanation is that the HashSHA1 element is of Hex40 type defined as

ome-model/specification/src/main/resources/released-schema/2016-06/ome.xsd

Lines 1467 to 1476 in e6efb88

	<xsd:simpleType name="Hex40">
	<xsd:annotation>
	<xsd:documentation>
	Binary contents coded in hexadecimal (20 characters long)
	</xsd:documentation>
	</xsd:annotation>
	<xsd:restriction base="xsd:hexBinary">
	<xsd:length value="20"/>
	</xsd:restriction>
	</xsd:simpleType>

So the 20 length restriction might not apply to the hexadecimal string but rather to its equivalent binary representation. This matches what Python binascii.unhexlify returns about the former value and the newer one

>>> from binascii import unhexlify
>>> len(unhexlify("1234567890ABCDEF1234567890ABCDEF12345678"))
20
>>> len(unhexlify("1234567890ABCDEF1234"))
10
>>> unhexlify("1234567890ABCDEF1234567890ABCDEF12345678")
b'\x124Vx\x90\xab\xcd\xef\x124Vx\x90\xab\xcd\xef\x124Vx'

[melissalinkert]

Following today's formats team discussion, removing HashSHA1 entirely from XMLMockObjects and re-including.

The longer-term solution is to update the schema to deprecate HashSHA1, and ensure that nothing else in our stack uses this feature. git grep HashSHA1 on https://github.com/ome/bioformats/tree/3d73a85c5af636cf5af42e952adae4e22611585b shows nothing.

[sbesson]

The original issue associated with the reading the Plane.HashSHA1 has been fixed downstream - see e.g. tlambert03/ome-types#146.

As discussed at the Formats meeting, a secondary problem is that the Plane.HashSHA1 carries the expectation to store a hash of the plane data. At the moment, this mock infrastructure will unconditionally store an arbitrary value which has the potential to create confusion for downstream consumers.

Given all the builds have been staying green with this PR included, I would agree to get it merged and included in the next ome-model release.