Automatically Deactivate Invalid 10up User WordPress Accounts

[bengreeley]

Description of the Change

This PR introduces functionality that will allow expired 10up accounts to be automatically 'deactivated'. The logic works as follows:

• After the daily message is sent to Support Monitor, it will run the functionality to check for user accounts that end in @10up.com or @get10up.com whether they are deactivated (no longer employed by 10up). This occurs after the message is sent so any deactivated users will still be flagged in Support Monitor to notify the project team.
• A new endpoint on the Support Monitor website, /wp-json/tenup/support-monitor/v1/is_user_deactivated will check for the environment authentication key before being able to be used and checks whether the e-mail addresses that are sent to the endpoint are active or not.
• For each 10up account that is flagged as deactivated, it will proceed to deactivate the WordPress user account on the site. Since the actual removal of a WordPress user could result in some unintended side-effects with data not being associated with an active user, this functionality will 1) Remove all roles for the expired user to effectively deactivate the account (the user will no longer be able to do anything on the site) and 2) reset the password to a random strong password to prevent being able to log in.
• This functionality can be turned off per-site by utilizing the filter tenup_support_monitor_deactivate_expired_tenuppers

Data flow is outlined at https://docs.google.com/drawings/d/1TSiC7LxwNBtQ6ojGTTdZuFuqmjA7_m_uC45TZ3eBIak/edit

Benefits

This will add an additional layer of security for 10up clients to ensure when a 10upper leaves the company that their account isn't able to be logged into on sites. When a user leaves 10up, their account is deactivated and SSO will no longer work, but their account still remains and the user could potentially still log in if they have set their password in the past. Not all 10up client projects utilize the SSO and users need to log in with a username and password.

Possible Drawbacks

There's an extra request from Support Monitor to the API endpoint during the daily report process. This isn't expected to add much overhead to the site.

Verification Process

To verify this functionality, I created accounts for e-mail addresses that are known to no longer be valid 10up accounts and gave them permissions to the site. When running the debug 'Sent Message' functionality I verified I am no longer able to log in as the user (password reset) and the user no longer has any roles.

Checklist:

• [x] I have read the CONTRIBUTING document.
• [x] My code follows the code style of this project.
• [x] My change requires a change to the documentation.
• [ ] I have updated the documentation accordingly.
• [ ] I have added tests to cover my change.
• [ ] All new and existing tests passed.

[bengreeley]

@tlovett1 @TheLastCicada If either of you guys have a chance to look at this sometime, I'd love to get your thoughts. I'm going to deploy the new endpoint that this functionality needs to the staging and production Support Monitor sites and it would be great if we could set it up on a couple of internal sites and test it out. I'd be interested in thoughts in regards to security and to try to poke any holes in the logic.