Implement static permission migration

Overview

OKAPI-839 investigated approaches to migrating static permissions during module upgrade. The outcome was a PoC and wiki page describing the preferred approach. This story follows that and formalizes/completes the implementation started in the PoC.

wiki page: https://wiki.folio.org/display/DD/Migration+of+Static+Permissions+Upon+Upgrade
PoC: https://github.com/folio-org/mod-permissions/pull/105

NOTE: this work spans both OKAPI and mod-permissions. This story covers the mod-permission portion only.

Jakub notes – to be verified with Craig: we have discussed the following changes compares to the PoC:

• the tenantPermission API call should be extended to include two lists: "module from" permissions and "module to" permissions, each list with the module name and version. Also, additional information about which permissions have been renamed should be available.
• mod-perms should persist the module name and version with each permission it stores in the DB
• once the module name and version is available, migrating permissions happens by overwriting (and renaming) old permissions with new ones. Permissions that are no longer defined in the new module version are "soft deleted"
• "soft deleting" mean s they are marked as "inactive" and removed from standard responses.
• "soft deleted" permissions can be retrieved and cleaned up using a dedicated API
• keeping "soft deleted" permissions around allows for downgrades of permission assignments
• since the current version of mod-permission does not persist information about module name and version, we face an initial migration challenge. We discussed that one way to deal with this problem is to have Okapi make an additional call to mod-permission with the "module from" permissions so that this missing information can be updated.