Refactor and audit access code

[sheagcraig]

This PR creates a level_required decorator, and staff_required decorator, and an access_required decorator to greatly eliminate redundant permissions testing, and redirection or error handling code.

• level_required allows you to decorate a view function with UserProfile.level values that should be allowed to proceed.
• staff_required allows you to decorate a view function that should only allow staff users to access them (these are entirely user management views).
• access_required allows you to specify that a view should only proceed for users who are either global admins, or have permission on the BusinessUnit that a view is retrieving data from. (This could be a BusinessUnit, a MachineGroup, or a Machine).

Additionally, as this was no minor undertaking, I broke up the server.views into three separate modules based on function (UI views, settings views, and non-UI views). Whenever I worked on some code, if it had unused code, redundant code, poor style, etc, I updated it.

For example, in several places the context for a view is initially populated with csrf(request). But then later in the view function the context is assigned a dict, overwriting the previous data. So those were all removed.

Tests are included for the decorators.

Annoyingly, I discovered a mistake in the (re-enabled due to another PR from me) the setting of "never" for your Sal version notification policy, which is fixed with a6d4b77

A number of lax permissions mistakes were discovered and corrected. I can summarize more specifically if desired, but these basically fell into several permutations:

1. Views which had no links to unprivileged users presented in the UI were still available if a properly formed request was made.
2. Some settings endpoints were available to any authenticated user.
3. Views were missing login_required decorator; this is minor as they all had more restrictive decorators additionally, but I put login_required in for consistency. (explicit is better than implicit and whatnot).
4. A properly formed request could get machine_detail_facter and machine_detail_conditions data with an authenticated but unprivileged user.
5. An unprivileged user who was a member of a Business Unit could delete machines!

During the course of this PR I also figured out how to override the User admin page, so I removed the UserProfile admin page and replaced the stock UserAdmin with a customized one that includes an inline UserProfile. (It's better!)

The "X Machine" delete-this-computer displayed on a machine detail view, even if the viewing user didn't have permission to actually delete a machine. The modal would not display, but I have thus removed the button entirely from the navbar.

The base template included a line that was supposed to show the logged in user's level. However, it had a typo and didn't display. Also, there's no easy way to know who you are logged in as, so I added a menu item that includes username and level to the menu.

Outstanding Issues

• We need to determine what Sal should do when a user should not have access to something. As it stands, there is a mix of redirects, 403, and 404.
• RW users are able to create, edit, and delete machines, and create and edit machine groups; but not delete them. Is this an oversight, or intended?

[sheagcraig]

There is still some work that can be done here; The plugin code expects
to come across plugins which are missing a plugin_type method, and which
have a wide range of type values which don't seem to be consistent.

I'm currently adding a plugin_type method onto those, which seems like a waste of processing time. In the future, I'll just create a SalPlugin class and all plugins will be expected to subclass it and override things if needed. It looks like most of the Sal plugins out in the wild are just copied and pasted from the ones that ship with Sal, so this kind of standardization would be good.

Regular plugins are excluding plugins with types machine_detail or report.
Reports are excluding plugins which don't have name == report
Machine detail plugins were excluding builtin, and full_page. I'm guessing this was historical, and I changed full_page to report.

I'm not seeing a huge need to override/implement a plugin_type method, so it seems like these could just be a class property, and could use a PluginType class/pseudo-typedef
(e.g.

class PluginType():
    builtin = 'builtin'
    machine_detail = 'machine_detail'
    # etc

class MyPlugin(SalPlugin):
    plugin_type = PluginType.machine_detail

I get why this stuff is here-we don't want to break existing working plugins. Perhaps this is something that could be overhauled during the upcoming next major version work, where there's less expectations that things will continue to work with no changes.

As it stands, I left # TODO comments about these in place so we can find them later.

I want to look over the code too and make sure that the plugin model reload is happening at the appropriate UI places, and not getting run elsewhere. It's a minor impact if it does, but it would help with the plugin refactor.

[grahamgilbert]

Are you happy with this now? I can start testing this during airport time on Monday.

[sheagcraig]

I thought you were going to be AFK all week, so I haven't pushed the last bit of stuff. But knowing you have airport time, I'll get it finished up ASAP.

[sheagcraig]

Let's call this good for now.

I have another chunk of code that I've identified to work on, but it can easily be completely separate from this. hint it's plugins.