Generic shares_base module and specific s3_datasets_shares module - part 11 (renaming and cleaning up s3_shares)

[dlpzx]

Feature or Bugfix

• Refactoring

Detail

As explained in the design for #1123 and #1283 we are trying to implement generic datasets_base and shares_base modules that can be used by any type of datasets and by any type of shareable object in a generic way.

This is one of the last PRs focused on renaming files and cleaning-up the s3_datasets_shares module. The first step is a consolidation of the file and classes names in the services to clearly refer to s3_shares:

• services.managed_share_policy_service.SharePolicyService ---> services.s3_share_managed_policy_service.S3SharePolicyService
• services.dataset_sharing_alarm_service.DatasetSharingAlarmService --> services.s3_share_alarm_service.S3ShareAlarmService
• services.managed_share_policy_service.SharePolicyService --> services.s3_share_managed_policy_service.S3SharePolicyService

👀 The main refactoring happens in what is used to be services.dataset_sharing_service.

• The part that implements the DatasetServiceInterface has been moved to services/s3_share_dataset_service.py as the S3ShareDatasetService
• The part used in the resolvers and by other methods has been renamed as services.s3_share_service.py and the methods for the folder/table permissions are also added to the S3ShareService (from share_item_service)

Lastly, there is one method previously in share_item_service that has been moved to the GlueClient directly as get_glue_database_from_catalog.

Relates

• Create generic shares_base and s3_datasets_shares modules from current dataset_sharing #1283
• Create generic dataset_base and s3_dataset modules from current datasets #1123
• Redshift Data Sharing #955

Security

Please answer the questions below briefly where applicable, or write N/A. Based on
OWASP 10.

• Does this PR introduce or modify any input fields or queries - this includes
  fetching data from storage outside the application (e.g. a database, an S3 bucket)?
  • Is the input sanitized?
  • What precautions are you taking before deserializing the data you consume?
  • Is injection prevented by parametrizing queries?
  • Have you ensured no eval or similar functions are used?
• Does this PR introduce any functionality or component that requires authorization?
  • How have you ensured it respects the existing AuthN/AuthZ mechanisms?
  • Are you logging failed auth attempts?
• Are you using or adding any cryptographic features?
  • Do you use a standard proven implementations?
  • Are the used keys controlled by the customer? Where are they stored?
• Are you introducing any new policies/roles/users?
  • Have you used the least-privilege principle? How?

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[petrkalos]

nit: all it does here is catch and rethrow so the block isn't required