OctoPrint 1.4 Compatible

OctoPrint 1.4 Compatibility

• Intitial refactoring by @paulkstelis (super-duper helpful!)
• Renamed some settings (with migrations) to avoid confusion with OctoPrint's internal groups (e.g. 'groupsbecameou` almost everywhere)
• Mapped LDAP group memberships on to OctoPrint groups, to allow for privilege assignment based on LDAP OU membership.

Look and Feel

• Broke the settings pane into multiple tabs
• Embedded more detailed documentation about settings into the settings dialog

Under-the-hood

• Internally, the plugin became too unwieldy to live in a single file, so it has been exploded into one-file-per-class
• A couple of helpful tweaks, constants and mixins were added to make the source code more readable and succinct
• Now correctly includes RestartNeedingPlugin mixin
• Updated requirements.txt to allow for better IDE integration
• Turned on scrutinizer-ci continuous integration to get some feedback on Pythonic goodness (since I'm not really a Python programmer).

This has been tested against the ForumSys LDAP test server and both local file-based users and LDAP users are able to authenticate to OctoPrint with credentials checked correctly, while non-users cannot authenticate. The ForumSys LDAP test server seems to run OpenLDAP, which empirically behaves differently in some respects (noted in the README) than the Microsoft LDAP server bound to Active Directory. This may be artifacts of our local AD/LDAP configuration, but I noted them for posterity in case others also run into this.

Authenticated Search, Caching

Settings-related changes

• Relocated settings to "normal" hierarchy (plugins/auth_ldap)
• Shortened settings names to reflect move (e.g. ldap_uri is now just uri)
• Prevented access to auth_ldap settings for non-admin users
• Added auth_user and auth_password settings to support authenticated searches of LDAP directory
• Added settings to allow for configurable search filters on LDAP
• Tweaked settings template name and content to correctly display stored settings
• Restructured get_default_settings() method to reflect changes described above
• To prevent double-caching LDAP users that have been searched for case-sensitively, the search_term_transfrom setting allows the specification of upper or lower to force the userid to be searched within the LDAP directory consistently using the same case.
• Default roles configuration added
• on_settings_migrate() implemented (along with get_settings_version() now reporting as 2), to "seamlessly" bring old-style settings into plugins/auth_ldap
• Separated the LDAPUserManager object from the AuthLDAPPlugin object, as there was a private member collision of self._settings -- one was inherited from the UserManager, the other from the SettingsPlugin, and accessing settings was behaving badly because of this. Now accessing settings within the plugin object should correctly access the plugin settings, and the plugin settings can be accessed from the LDAPUserManager via the plugin_settings() method.

LDAP-related changes

• Added LDAPUser class extending User, which stores the distinguished name of the user in the LDAP directory (and lets us differentiate between file-based and LDAP users)
• Rewrote FindUser() and CheckPassword() methods and supporting LDAP methods to allow for optional authenticated searches of the LDAP directory
• Group filters are applied both when searching for users initially and when validating passwords (as assignments, configuration may have changed in the interim if the LDAP user is cached locally.
• LDAP users that have been cached locally have their active level verified before checking their password
• User-entered LDAP search strings are now escaped using the python-ldap library

Documentation-related changes

• README has been updated to reflect current behavior
• Suppressed some of PyCharm's more vexing inspections (which are detecting real things, but where I have to use "poor style" to be either consistent with or access the OctoPrint framework. Feh.

This has been tested against the ForumSys LDAP test server and both local file-based users and LDAP users are able to authenticate to OctoPrint with credentials checked correctly, while non-users cannot authenticate. The ForumSys LDAP test server seems to run OpenLDAP, which empirically behaves differently in some respects (noted in the README) than the Microsoft LDAP server bound to Active Directory. This may be artifacts of our local AD/LDAP configuration, but I noted them for posterity in case others also run into this.