Add operations to remove and restore shared drive permissions

Commit history shows the journey of this MR...

Key points

• added option to scan just a single drive
  • allows you to make sure the share drive cache is up to date before removing permissions
  • initially had a --force-rebuild but later changed to rebuild the list of shared drives in the cache by default and have a --skip-rebuild
• move the scanning of a drives "root" permissions to when the drive is scanned rather than when the list is updated
  • keeps drive and augmented permissions scan times in sync
  • rebuild of drive list can happen quicker (hence switch to doing it by default) - should no longer attempt to scan a deleted drive
• change shared drive cache writing to first re-read the existing cache file
  • could be hours since it was read by this long running operation
  • two operations updating the cache file are less likely to trample on each others work
  • e.g. doing a single drive scan while a scheduled batch are being worked on
  • not full-proof but consequence of using a file rather than DB - let's not go there yet!

With all the refactor out of the way:

• Add operation to remove shared drive permission (including augmented file permissions)
  • much messing around with having to have a management user be a organiser of the drive so the augmented permissions can be removed
  • also horrible merging if a recovery file already exists
• Add operation to recovery shared drive permissions from a recovery file
  • similar management user shenanigans
• Check to make sure shared drive recovery cleanup does mess with shared drive recovery files - for now

Actual performing these actions against test shared drives on gdev instance discovered I was calling the GoogleDriveConnection functions with the wrong format of dicts/lists. All fixed and tested removal and restore against a shared drive with augmented permissions.

Part of #35 (closed)