Fix: add sharing guardrails drop permissions

[dlpzx]

Feature or Bugfix

• Feature
• Bugfix

Detail

This PR should be tested and reviewed after #1016 is merged.

data.all pivot role is a Data Lake admin in Lake Formation. However, to drop tables and databases "DROP" permissions are required, even for Data Lake Admins. In order for the revoke processes to work correctly, we need to ensure that these permissions are granted to the pivot role for data sharing glue resources (shared database and resource link tables) in all situations.

One of this scenarios is the migration from manual to auto-created pivot roles and vice-versa as reported in #1053 . Other cases involve manual actions on existing resource links. To avoid any potential issue and make the revoke more robust, this PR explicitly grants DROP permissions on tables before deleting them. And grants "ALL" permissions on the shared_db database.

Tested locally:

• Create 2 environments with manually created pivot role and create, submit and approve a share request with tables.
• Change the configuration to use auto-created pivot roles and revoke the share. The tables are revoked successfully

Relates

• Migrating from manual pivotRole to cdkRole makes table shares unrevokable #1053

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.

[zsaltys]

LGTM

[noah-paige]

lgtm