Clarify that calls to logMessage must respect log settings

[pmai]

Closes #2072 for the standard side of things.

[chrbertsch]

FMI Design Webmeeting:

Klaus: This does not reflect the notes #2072 (comment). Was there another conclusion at the on-site meeting that we did not document.
As stated in the original issue I am not happy with the proposed solution.,
Masoud: I agree with Klaus.
Torsten: Me, too. The way the reference FMUs implement it, is the way to go.
Changing the standard would not break anything. It is a bugfix.
Nikolai: do the log categories "error" and "fatal" not be come useless?
Klaus, Torsten: Almost no FMUs use these categories. This is just a suggestion.
Klaus, Torsten: There is in the standard a mixupt of status and logCategories for errors ...
Torsten. Klaus: We should admit that we made a mistake and fix this "bug" the standard.
Torsten: We would legalize most implementation.

@pmai : could you please give your rationale?

[pmai]

The PR reflects the consensus that was reached in the F2F meeting as far as I recall I was just the implementing person:

• Section 2.3.1 clearly states that logMessage cannot be called when loggingOn is false.
• Section 2.2.4 correspondingly states that non-OK results should be accompanied by corresponding logMessage calls, respecting current logging settings. It does so for all return values, i.e. even for fmi3Error and fmi3Fatal. And that was very explicitly put there during 3.0 development, so seems to indicate a consensous position that logging settings should actually be heeded.
• While the statements changed in the PR seemingly contradict the other statements, they never do so explicitly, i.e. they never state that this should happen even if loggingOn is false - they just use wording that can be interpreted to mean this, and from revision history were likely just overlooked when the explicitly language in 2.2.4 and 2.3.1 were added.

Therefore, whether we like it nor not, the conservative way to resolve the seeming discrepancies is to resolve them in favor of not logging of loggingOn is false, which the PR does. This also seems to match the spirit of the changes in e.g. section 2.2.4 which was explicitly changed to add the respecting logging settings language (otherwise the logging settings also make little sense, if they are disregarded all over the place, so this seems to me also to fit the principle of keeping APIs to follow the least surprising behavior).

If we changed this in the other direction it would more or less invalidate the whole logging settings in the first place, as they would then be consistently ignored, at least for errors. It would also make other changes necessary, as e.g. you are allowed to pass in a NULL pointer for logMessage, but only if that functionality is not used - since ignoring loggingOn would always potentially use the functionality, you could no longer do this.

So in summary changing in the other direction seems hardly a backward-compatible change, nor a very necessary one. If an implementation gets an error, especially during instantiation which triggered the current discussion, with loggingOn=false, they can just repeat that call with loggingOn=true to get more detailed information. Or if they care, they can always run with loggingOn. In practice we have the problem that some FMUs seem to default to lots of silly nuisance logging in that case - however a proper solution to this would have been to allow filtering logMessage by severity level - rather than the log categories. We did not do this correctly, but changing 3.0 semantics years after the fact seems a fairly bad way of handling this screw up - and unlikely to have any impact anyways:

Personally I don't care very much what we do here, btw, as everyone feels free to ignore what we write here anyways, so it hardly matters.

[chrbertsch]

We will continue to fix #2072 in #2097, see comments there.