Inconsistent processing of discovery properties

[pgaufillet]

Hi!

I think I have found an inconsistency in the way discovery properties are managed. In ZigBeeNodePropertyDiscoverer.java, l.170 and l.179, the _PROPERTYVENDOR and _PROPERTY_MODELID are trimmed out:

properties.put(Thing.PROPERTY_VENDOR, manufacturer.trim());

properties.put(Thing.PROPERTY_MODEL_ID, model.trim());

It removes whitespaces and invisible characters from both ends of the String. But since 2022, it is possible to specify any unicode characters in discovery.txt. In ZigBeeThingTypeMatcher.java:

newProperties.add(new RequiredProperty(discoveryElement[0].trim(), unescape(discoveryElement[1].trim())));

It is used in particular for Legrand devices:

legrand_dimmer_without_neutral,vendor=\u001f Legrand,modelId=\u001f Dimmer switch w/o neutral

In this case, '\u001f ' never matches. And it is indeed what I observe with OpenHab Zigbee 4.1.2: Legrand Dimmers are not correctly recognized. There are 2 options for solving this issue:

1. Remove the invisible characters from discovery.txt from the ends of the properties (in this case, unescape() has only a role for characters between visible characters),
2. Remove the trim() function calls from ZigBeeNodePropertyDiscoverer.java (in this case, the recognition of vendor specific devices shall be revalidated).

[cdjackson]

I think I would probably opt for the first option. IIRC we otherwise had problems in the past with whitespace and it feels more robust to me to remove the unprintable characters.

I'm open to being convinced otherwise though if there's a strong reason...