Add badge indicators for pending published changed

[GUI]

One of the most common configuration mistakes we see is admins not publishing their changes after making the changes to API Backends or Website Backends. I think we want to keep this explicit "publish" step for various safety reasons, but highlighting the need for publishing the pending changes I think would go a long way to reducing these configuration errors.

So the idea here is add a badge to the "Configuration" menu in the admin that would highlight anytime there were pending changes (and then the badge would go away if there were no changes). Here's a mockup of what this could possibly look like (using bootstrap badges):

The badge could be added both to the "Configuration" menu so it would be most visible, and then a matching badge to the "Publish Configuration" menu item so that it would be obvious what section this was tied to.

In order to do this, I think a few different steps would be necessary:

1. Trigger a request to the /api-umbrella/v1/config/pending_changes.json API endpoint after any API Backend change, Website Backend change, or publishing itself happens in the admin UI.
2. From that pending_change.json response, figure out the pending count, and then add/remove/update the badge from the menus as appropriate.
3. Other approaches / optional followup work: The pending_changes.json request may be slow to run, so this may not be the best fit for making this type of frequent request. For example, it takes about 3s for this request to complete for me in production (although, it may not be as slow for non-superuser admins). But a few other ideas of things we could do to improve this:
   • Create a variation of the API, like pending_changes.json?counts_only=true that may be able to return more quickly if it's optimized around just returning the counts. I'm not 100% sure where the bottlenecks are currently, but if it's in generating some of the YAML content for the diff purposes, we could maybe come up with a simpler response format for just the counts.
   • Alternatively, we could look to optimize the full pending_changes.json if the bottlenecks are more fundamental, but that API still returns a boat load of unnecessary data, so I think the counts-only response could still make sense.
   • If adding hooks to make this separate request to pending_changes.json after each change proves difficult, we could also consider integrating this pending count data into the underlying API Backend and Website Backend POST/PUT requests, so that when changes are made, it's contained directly as extra metadata on that request.