Generic shares_base module and specific s3_datasets_shares module - part 10 (other s3 references in shares_base)

[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 PR:

• Remove the delete_resource_policy conditional for Tables in backend/dataall/modules/shares_base/services/share_item_service.py --> Permissions to the Table in data.all are granted once the share has succeeded, the conditional that checks for share_failed tables should not exist.
• Remove unnecessary check in share_item_service: in add_share_item we check if it is a table whether it is a cross-region share. This check is completely unnecessary because when we create a share request object we are already checking if it is cross-region
• Use get_share_item_details in add_share_item - we want to check if the table, folder, bucket exist so we need to query those tables.
• Move s3_prefix notifications to subscription task
• Fix error in query in backend/dataall/modules/shares_base/db/share_state_machines_repositories.py

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.

[dlpzx]

Testing:

• Try to open a cross-region share request - we get an unauthorized error
• Verify table shared permissions: When the table is in Share_Succeeded, the requester has read table permissions. When the table is Revoke_Succeeded, the requester loses the read table permissions.
• update_share_item_status_batch used in share transitions as expected -> tested in Approve share object = all items are updated in batch

[noah-paige]

all the specified changes look good and tested shares still working as expected - approved!