Avoid showing label for unknown event type

[aduth]

🎫 Ticket

Related to LG-11867

🛠 Summary of changes

Updates logic of EventDecorator#event_type to avoid trying to return a human-readable label for an event type that is not known to the application.

This isn't a typical behavior, but the included inline code comment explains the circumstances where it can occur:

# If the database has an event type value which isn't known to the application, it will be
# parsed as nil, which can result in unexpected behavior for retrieving a string label. This
# can happen during deployment of a new event type, where old servers aren't yet aware of the
# new event type, or it can happen if values are erroneously removed from the model enum while
# existing database records still use the value.

As an aside, tracking existing references to EventDecorator#event_type can be tricky since the name is the same as Event#event_type, where only the decorator returns a human-readable label. This label is used on the History and Devices pages. In the future, it could be worth renaming this method to more clearly differentiate (e.g. readable_event_type, or event_type_label)

📜 Testing Plan

Repeat Testing Planf rom #11823 and then switch to this branch. The History page should not show any text for the events associated with adding or removing Face or Touch Unlock. Previously, this would show all of the event_types.* labels as a stringified hash.

👀 Screenshots

Before	After