FIX: more error handling for ElogPoster

[ZLLentz]

Description

This comes from a hotfix in rix3 that I added onto here.

There is a niche issue where "something" gets loaded as the elog but it isn't a valid elog object. Then, this script picks up the non-elog item and passes it to the ElogPoster, which starts causing an issue (text spam? I don't quite remember) when you try to run a scan later.

This PR rearranges the error reporting a bit and includes a check that the expected objects haven't been replaced.

Motivation and Context

• Working through hotfixes as part of https://jira.slac.stanford.edu/browse/ECS-6333
• Can cause an annoying error spam if the user makes an elog object, instead just fail the ElogPoster in red text

How Has This Been Tested?

Interactively only, checking the error messages

Where Has This Been Documented?

Here only

Pre-merge checklist

• Code works interactively (a real hutch config file can be loaded)
• Code contains descriptive docstrings, including context and API
• New/changed functions and methods are covered in the test suite where possible
• Test suite passes locally
• Test suite passes on GitHub Actions
• Ran docs/pre-release-notes.sh and created a pre-release documentation page
• Pre-release docs include context, functional descriptions, and contributors as appropriate

[tangkong]

Seems like elog was never an explicit dependency on the pip-side, weird (not weird, it's not on pypi)

I forget, why haven't we added it to pypi?

[ZLLentz]

It must be some issue with a dependency of a dependency that we couldn't get onto pypi

[ZLLentz]

For this PR, I'll just protect the import in the safe load or in a try/except

[ZLLentz]

The actual answer is probably that elog is already taken on pypi

[tangkong]

ah yes. PyPi's elog is an unmaintained elasticsearch log system https://pypi.org/project/elog/

Proposals for names? lcls-elog? explog? the-elog?

Of course we already have an issue for this. pcdshub/elog#30

[tangkong]

Seems like a good fix.

[tangkong]

I guess this is something the hint banner could also fall prey to, if someone overwrites an existing namespace global.

I think it's maybe a small miracle that we haven't hit upon a case where a hutch overwrites one of our helpful namespaces (a, m, etc). Or maybe they just don't use those and access the motors by name explicitly. 🤷