cloudmeter mismatch notification state should refresh based on filters

[ntkathole]

Description

When there is mismatch at SLA/Usage level, mismatch notification should display only for selected filters. Currently if any of the filter is mismatched, notification does not change its state based on selected filter.

Expected behavior

cloudmeter mismatch notification state should change based on filters.

Steps to reproduce

1. Have account with 2 hosts as following :
   cloudmeter reported - 2 premium hosts, while,
   RHSM reported - 1 premium and 1 standard host
2. Above account will display mismatch when standard and premium sla filter is selected, but it should not show mismatch when unspecified or self-support sla is selected.

Additional context, version info

As we don't refresh notification based on filters, it may possible that user can see mismatch for some filters, which he/she should not. In below gif, notification should not display for self-support filter.

[cdcabrera]

During initial development we attempted to vary the banner display based on filter as this issue notes. However, the banner kept appearing and disappearing similar to what's displayed in the gif. It was decided via UX @bclarhk @rblackbu that once the banner turned on it should stay on until the end-user either manually closes it, and/or a page refresh happens resetting the banner display parameters. This behavior is described in the initial PR #503 notes area.

This issue is slightly interrelated to the behavior of #511 fixing this issue may help resolve parts of this behavior, or the behavior we witnessed during initial development.

Overall this issue highlights a behavior that the banner is working as intended and that NOT turning the banner on and off relates a purposeful UX decision. @bclarhk @rblackbu

[bclarhk]

The banner should display if there's a mismatch on any of the RHEL systems. It's positioned above the filters for this reason.

HOWEVER...

It looks like the banner is not displaying on the initial page load. This is wrong but may need a new issue (if it is indeed a bug) to avoid confusion. Is the default result set provided by the API for Tally, Capacity, and Hosts not all inclusive?

[cdcabrera]

Breaking out the @bclarhk explanation further... The stated intention for the banner is

"[Any system that has a data mismatch means the banner should show outside of the user selected filter behavior]"

That being said, technically the banner should show immediately when a user jumps into a page if any product aspect is "mismatched". However that would be a little intense for the GUI to call every possible API Tally endpoint and filter combo to display an error that's really just the API needing a resolution between end-points, Tally and inventory... something like 4+ API calls... so instead the GUI does the lazy approach... and simply rides off the user picking filters even though the intention is "to be outside of the user picking filters".

The original intention behind the mismatch flag on Tally was for some level of icon and/or tooltip display in the graph. We leveraged that intention for a banner message instead. The banner message pushes the boundaries of that original intention and causes some curious behavior. Tally and the GUI are currently performing as expected.

For the future there are a few possible paths... we can open issues accordingly as an evolution of this issue

1. It may be to our benefit to consider a dedicated API message endpoint to help call out future issues. This could easily tie into a GUI "message center"
2. Confirm that a resolution on the API side for the mismatch between Tally and inventory is being addressed. And on the GUI side we simply turn the "mismatch" banner off
3. If we maintain an "API message" that is dictated by a user selected toolbar filter we consider using toast notifications and a possible side tray message center instead of banners to avoid page jump