cleaned up logging output

[PietroPasotti]

Fixes #796

Got rid of a few 'unhelpful' debug logger calls.

Checklist

• [n/a] Have any types changed? If so, have the type annotations been updated?
• [n/a] If this code exposes model data, does it do so thoughtfully, in a way that aids understanding?
• Do error messages, if any, present charm authors or operators with enough information to solve the problem?

QA steps

• I ensured that all 'exceptional' code paths still result into SOME logging output, while the 'normal' behaviour is more silent.
• The logging output was used in unittests to check that a given branch was being executed; I removed those checks but we might want to replace them with other types of checks, so as not to lose coverage.
• Is there any chance that 3rd party code is also relying on our logging output to do things? Are log streams considered 'private'?

Changelog

• Cleaned up ops.main logging output.

[marcoppenheimer]

This looks great, thank you!
Although possibly out of scope, the Operator Framework 1.5.0 up and running. logs have limited use/interest for the user. Would we ever expect this not to be the case? If it wasn't, would a user be able be reasonably expected to do anything about it?

That said, Penny's comment on them makes sense, might we change the output to something richer? I don't have strong opinions on this though.

Inspiration

• <CHARM_NAME> run started with <X> <Y> <Z> env vars - X Y Z being interesting ones.
• ------------- <UNIT NAME> started ------------- - Just for demarcation of runs when using juju debug-log --include-module unit.<app>/N or something. Kinda ugly though.

[PietroPasotti]

This looks great, thank you! Although possibly out of scope, the Operator Framework 1.5.0 up and running. logs have limited use/interest for the user. Would we ever expect this not to be the case? If it wasn't, would a user be able be reasonably expected to do anything about it?

That said, Penny's comment on them makes sense, might we change the output to something richer? I don't have strong opinions on this though.

Inspiration

• <CHARM_NAME> run started with <X> <Y> <Z> env vars - X Y Z being interesting ones.
• ------------- <UNIT NAME> started ------------- - Just for demarcation of runs when using juju debug-log --include-module unit.<app>/N or something. Kinda ugly though.

I wouldn't mind at all having a broader 'welcome' log on start/install, or anyway when the OF fires up for the first time.
We don't need to be reminded of the OF version on each hook call, do we? But as @pengale said it is handy to know.

We could specialize log output:

• when the first hook ever runs on this unit: log "Operator Framework [VERSION] running charm [CHARM NAME]." The unit name prefix tag is added by juju so we don't need to worry about that.
• on any hook run, simply say (as we already do I believe) "firing event [EVENT NAME]"

[pengale]

(A richer log message on start also makes sense, though possibly part of a separate PR.)

[rwcarlsen]

Just one small recommendation.