Fixes #39083 - Use Action Cable for UI notifications

[jeremylenz]

This change (mostly) eliminates web UI polling to GET "/notification_recipients" in favor of a WebSocket connection via Rails Action Cable.

To test:

Load the web UI in the browser
Get a new notification (I used host details > Refresh applicability, but you can do anything that causes a notification in the notification bell) OR clear a notification / mark as read

Before: in the browser dev tools Network tab, you will see polling to /notification_recipients every 10 seconds.
After: No polling. Instead, you will see a "Socket" request to GET /cable and notifications should appear immediately

[jeremylenz]

this is from the rails example and needs to be fixed

[jeremylenz]

@ehelms Do you know what the correct value is here, for the production redis server?

[ekohl]

It's configurable and I'd expect that the installer manages the file to configure this. I think this file should likely be one of those things where we ship a .example, similar to settings.yaml.

[jeremylenz]

I started out with async adapter, but turns out it's really unreliable because the message sender (broadcaster) and client have to be on the same process, or else the message is not received. Redis seemed to be available already, and works well in my development environment. I assume it would also work in production, but I'm not quite sure of the correct configuration and will probably need some help there.

[ekohl]

As I said in https://community.theforeman.org/t/revisiting-action-cable-for-notifications-6-years-later/45738/2

First reaction when I saw the title: yes please.

I'd love to see how it scales. What if you connect 100 or 500 clients, what's the impact?

Security wise: is a channel disconnected when a user is deleted?

[jeremylenz]

Security wise: is a channel disconnected when a user is deleted?

I tested this by deleting a non-admin user in Rails console while a REX job was in progress. In the chrome dev tools Network tab (filtered to "Socket" type) the GET /cable request pings were still active. I guess this is because the user authorization is done during def connect only.

However, the user never actually got the notification about the job being complete.

^ I guess this explains that -- the job stalled because the user disappeared.

However, when a user closes or reloads the browser tab, the cable consumer is disconnected, and any subsequent attempts would require authorization again.

I'd love to see how it scales. What if you connect 100 or 500 clients, what's the impact?

Not sure, but since we're eliminating those API requests every 10 seconds I'd guess it's a net positive.

In reality I'd think the Foreman web UI isn't going to have more than a dozen or so simultaneous users.