[MQTT] Fix tests after core change

[mherwege]

See openhab/openhab-core#4169 (comment)

Some MQTT tests with QuantityTypes fail after openhab/openhab-core#4169 because the MQTT binding assumes a format pattern of %s to drop the unit of the Number with Dimension. As this was changed in core, this PR introduces some logic in the MQTT binding to account for this.
All failing tests have run again and pass.

Also, default formatting for Number types was not in line with the documentation. It used %s, while the documentation states it should be %f, dropping all decimals (and the unit). It now is for Number types.

[mherwege]

All test run through fine locally.

The change is in the org.openhab.binding.mqtt.generic package and that should solve the issue for the tests in both the org.openhab.binding.mqtt.generic and org.openhab.binding.mqtt.homeassistant package. Can it be that when running the tests for the org.openhab.binding.mqtt.homeassistant package, it still works with the unchanged compiled code of org.openhab.binding.mqtt.generic? When I run this in my IDE with both packages open and the changes I made, all tests pass.

[lolodomo]

LGTM, thank you

[lolodomo]

I am annoyed by the failing builds...

[mherwege]

I am annoyed by the failing builds...

Agree. It was working for me in Eclipse. But it looks like Eclipse might not have had the last QuantityType changes. Looking into fixing this.

[mherwege]

@lolodomo It should be much better now.

The key challenge remains though that the format method in the core types is used both for formatting for display and when doing these transformations. It leads to all kinds of funny effects.
E.g. if you use %.1f as a format pattern, depending on your locale, you will get a . or ,. That is what you want in the UI, but not in a transformation. And that basically means one has to cope with exceptions in many places. By default transformations will use %s. That should keep everything... except it used to drop the unit from a QuantityType before openhab/openhab-core#4169, which was not nice from a UI perspective, and it caused errors when updating from the UI when the unit was not the default unit.
Simply using a %.0f format on QuantityType works to get you the numeric value, but without digits. %.1f would be locale dependent.
I believe it is solved for all cases in the test set, but I cannot guarantee there are no configurations out there that may have a slightly different behaviour depending on the pattern used. I hope I have been as little intrusive as possible.