Ensure deprovisioning management command deletes DMC

[jamalex]

Summary

We weren't clearing the DatabaseMaxCounter table when deprovisioning, which could impede the same data from being synced in again following a deprovisioning run.

Testing checklist

• Contributor has fully tested the PR manually
• If there are any front-end changes, before/after screenshots are included
• Critical user journeys are covered by Gherkin stories
• Critical and brittle code paths are covered by unit tests

PR process

• PR has the correct target branch and milestone
• PR has 'needs review' or 'work-in-progress' label
• If PR is ready for review, a reviewer has been added. (Don't use 'Assignees')
• If this is an important user-facing change, PR or related issue has a 'changelog' label
• If this includes an internal dependency change, a link to the diff is provided

Reviewer checklist

• Automated test coverage is satisfactory
• PR is fully functional
• PR has been tested for accessibility regressions
• External dependency files were updated if necessary (yarn and pip)
• Documentation is updated
• Contributor is in AUTHORS.md

[rtibbles]

I forget if we've discussed this before, but should we be consolidating the deprovision command with the other deletion utilities for deleting a Facility? https://github.com/learningequality/kolibri/blob/develop/kolibri/core/auth/utils/delete.py

[jamalex]

I forget if we've discussed this before, but should we be consolidating the deprovision command with the other deletion utilities for deleting a Facility? https://github.com/learningequality/kolibri/blob/develop/kolibri/core/auth/utils/delete.py

It does seem like there would be some room to refactor in order to share code, yeah.

[rtibbles]

Tests describe the fix, and the code changes fix it.

[rtibbles]

This is mostly my own ignorance, but why don't we want to delete the Buffer?

[jamalex]

It ForeignKeys onto the TransferSession, so it was redundant -- it does still get deleted.