Filter current user from resource permissions

[shreyas-goenka]

Changes

The databricks terraform provider does not allow changing permission of the current user. Instead, the current identity is implictly set to be the owner of all resources on the platform side.

This PR introduces a mutator to filter permissions from the bundle configuration at deploy time, allowing users to define permissions for their own identities in their bundle config.

This would allow configurations like, allowing both alice and bob to collaborate on the same DAB:

permissions:
  level: CAN_MANAGE
  user_name: alice

  level: CAN_MANAGE
  user_name: bob

This PR is a reincarnation of #1145. The earlier attempt had to be reverted due to metadata loss converting to and from the dynamic configuration representation (reverted here: #1179)

Tests

Unit test and manually

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 85.36585% with 6 lines in your changes are missing coverage. Please review.

Project coverage is 52.15%. Comparing base (16a4c71) to head (b2c68ee).

Files	Patch %	Lines
bundle/permissions/filter.go	85.36%	4 Missing and 2 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1262      +/-   ##
==========================================
+ Coverage   52.07%   52.15%   +0.07%     
==========================================
  Files         314      315       +1     
  Lines       17877    17918      +41     
==========================================
+ Hits         9310     9345      +35     
- Misses       7877     7881       +4     
- Partials      690      692       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[shreyas-goenka]

The CLI integration tests pass on this PR. Nightlies are green.

[andrewnester]

Do you really need this clause? The condition below will fire up earlier anyway if I understand correct and you won't go further than taht

[shreyas-goenka]

Yeah you are right, it'll be the same. If in the future the permissions block becomes more complex though this will act as another boundary condition. Being more conservative about the boundary conditions helps reason about it better IMO.

[andrewnester]

It works both ways, additional conditions add additional cognitive load into what is happening. From what we're trying to achieve, the code might have looked like

if len(p) == 4 && len[2] == "permissions" {
// do mutation
}

return v, nil

if you inverse this it will look like

 if len(p) != 4 || len[2] != "permissions" {
   return v, nil
 }
 
 // do mutate

It does not utilise ErrSkip though but makes it easier to reason about