Revise 'inCondition' logic in IPMI SDR alert job.

[brianparry]

This diff makes the following changes to the IPMI SDR poller.

1. Publish an alert with 'inCondition' asserted for each SDR reporting a fault.
2. Correct the key used to get saved inCondition values for each sensor ID.

@RackHD/corecommitters @benbp @VulpesArtificem

[brianparry]

Unit tests are failing:
https://roebling.hwimo.lab.emc.com/jenkins/job/Pull%20Request%20Builds/job/on-tasks-dev/136/

I'll fix and update the PR

[brianparry]

Unit tests fixed

[benbp]

To make sure I'm understanding correctly from the code/your comments:

1. This fixes a bug where we weren't doing lookups properly because of the '_' and '.' sanitization?
2. Publish an alert every time we see inCondition as true, even if we've already published that same alert before.

Sound right, or off the mark?

[benbp]

👍

[brianparry]

@benbp Your understanding is correct. This is a little different from the original logic we requested, but reduces the probability of missing events. LTAE has logic that understands alert uniqueness so it will not log a new alert each time the poller runs.

[AlliumApotheosis]

👍

[benbp]

@brianparry sounds good. Note that we still have the same missed event probability for inCondition: false events that are only published once. I think probably the best way to handle this is to set the IPMI alerts AMQP queue to be persistent, or change the alerter to create database entries + events, so that messages are guaranteed delivery.