[TT-1802] Clean up Stow locations when deleting middleware

[jlucktay]

Description

The handler to delete middleware was not cleaning up containers for either of the two different kinds of stow location in use by MServ i.e. local and s3.

api package

(api.API).HandleDeleteBundle(...)

• added calls for the following:
  • stow.Walk removes each item from the container (necessary for S3) (10a6774)
  • (stow.Location).RemoveContainer removes the empty container itself (d63b6d4)
  • os.Chdir is necessary to workaround a shortcoming in how stow handles local containers: RemoveContainer for local seems incorrect WasabiAiR/stow#239 (aeb5c36)
• refactored to get middleware from store at start of handler but not delete from store until the end, to reduce overall chance of failure leaving orphaned middlewares behind (de2b1eb)

General

• exported the FmtPluginContainer format string used for container name layouts (94705cb, 81b5a70)
• used exported stow.Kind consts in GetFileStore() rather than hard-coded strings (18cf3d3)

http_funcs package

• added TestDeleteMW to cover the existing and updated functionality of the API's delete handler (1cb44d8)
• broke tests and their helpers down across several files, instead of just one (cba2f6c)

conf package

• refactored to add a Reload() func which will flush the current config and re-read data (c8e1a32)

util/conf package

• added Flush() to facilitate conf.Reload()

util/storage/mock package

• implemented some funcs necessary for increased test coverage

Miscellaneous

• disabled maligned in the golangci-lint config file, as it has since moved into go vet (8cfe5ee)

Related Issue

TT-1802.

Motivation and Context

End users don't want S3 buckets left lying around after they delete a middleware.

Test Coverage For This Change

Added TestDeleteMW, and ran some integration tests on my local, to cover both local and s3 kinds of stow locations.

Screenshots (if appropriate)

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• Make sure you are requesting to pull a topic/feature/bugfix branch (right side). If PRing from your fork, don't come from your master!
• Make sure you are making a pull request against our master branch (left side). Also, it would be best if you started your change off our latest master.
• My change requires a change to the documentation.
  • If you've changed APIs, describe what needs to be updated in the documentation.
• I have updated the documentation accordingly.
• Modules and vendor dependencies have been updated; run go mod tidy && go mod vendor in applicable directories.
• I have added tests to cover my changes.
• All new and existing tests passed.
• Check your code additions will not fail linting checks:
  • gofmt -s -w .
  • go vet ./...
  • golangci-lint run