Added msg count endpoint and badge

[dlmarion]

Adds a badge containing the count of critical or
high messages to the Messages link in the NavBar.
If the number of critical messages is > 0, then the
badge is red with the number of critical messages.
Otherwise, if there are high messages, then the
badge is yellow with the number of those messages.

Added an API endpoint to return the underlying counts
which does not use the same query parameters that are
used with the switches. This means that counts will reflect
messages that may not be seen on the messages page
if the user has a switch turned off. This will allow for users
to be notified that there are messages that they might not
be seeing.

[dlmarion]

Screen shots:

[DomGarguilo]

It seems like it would be simpler and also avoid any unintentional drift to just use the size of the existing messages collection instead of maintaining a separate count. Is there a reason you have avoided doing that so far?

[dlmarion]

It seems like it would be simpler and also avoid any unintentional drift to just use the size of the existing messages collection instead of maintaining a separate count. Is there a reason you have avoided doing that so far?

The separate count is so that a different color can be used for higher priority messages. Regarding the drift, are you seeing that the counts would not be accurate?

[DomGarguilo]

Something else that I just thought of is if there might be a better name instead of "Messages" here. To me that reads almost as human-to-human messaging. Two alternatives I could think of are "Notifications" and "Alerts". I think alerts fits the best since notifications seems like pieces of information that tracks whether a user has seen them or not which is not the case here.

Curious the hear others opinion/ideas on this. Also not certain this should be handled in this PR or another.

[DomGarguilo]

It seems like it would be simpler and also avoid any unintentional drift to just use the size of the existing messages collection instead of maintaining a separate count. Is there a reason you have avoided doing that so far?

The separate count is so that a different color can be used for higher priority messages.

Yea I think its good to have the separate endpoint and be able to show the counts but I think we should be able to compute the count per MessagePriority when serving the endpoint right?

Regarding the drift, are you seeing that the counts would not be accurate?

I think it would probably be fine but since messages is a set, if we addMessage() or removeMessage() with a duplicate message or a message that does not exist its possible for the new counter could be incremented (or not) out of sync with the set.

[dlmarion]

It seems like it would be simpler and also avoid any unintentional drift to just use the size of the existing messages collection instead of maintaining a separate count. Is there a reason you have avoided doing that so far?

The separate count is so that a different color can be used for higher priority messages.

Yea I think its good to have the separate endpoint and be able to show the counts but I think we should be able to compute the count per MessagePriority when serving the endpoint right?

Why compute it N times when you could compute it once?

Regarding the drift, are you seeing that the counts would not be accurate?

I think it would probably be fine but since messages is a set, if we addMessage() or removeMessage() with a duplicate message or a message that does not exist its possible for the new counter could be incremented (or not) out of sync with the set.

That's a good observation, I think I can handle the duplicates easily.

[DomGarguilo]

Why compute it N times when you could compute it once?

Yea thats fair. Thats the tradeoff i guess. It would be an O(n) operation each time on a relatively small set which should be cheap right? It just depends if we think that cost is worth it for simpler logic pulling from a single source or truth.

[dlmarion]

I moved the message count computation to a single method that is called last in the finish method. This should make the counts accurate.

Something else that I just thought of is if there might be a better name instead of "Messages" here. To me that reads almost as human-to-human messaging. Two alternatives I could think of are "Notifications" and "Alerts". I think alerts fits the best since notifications seems like pieces of information that tracks whether a user has seen them or not which is not the case here.

I have no issue renaming Messages to Alerts. I can do that in a follow-on PR.