direct: when deleting resources, treat 403 as 404 (#3931)

## Changes
During "bundle destroy" or "bundle deploy" with resource deleted, 403
errors will result in warning rather than hard error.
This does not affect recreate, which still results in hard error.

## Why
If users don't have permissions to a resource for whatever reason, they
need to unbind it in order to make their bundle usable or destroyable.
This automatically unbinds.

We also saw that jobs service maintains permissions for deleted jobs, so
even if job does not exist, deleting it still results in 403 error.
Aborting "bundle destroy" in this case does not seem helpful.

## Tests
Existing integration test added in
#3922

Author: denik

…with_permissions/out.destroy1.direct.txt …/with_permissions/out.destroy.direct.txtacceptance/bundle/resources/permissions/jobs/destroy_without_mgmtperms/with_permissions/out.destroy1.direct.txt renamed to acceptance/bundle/resources/permissions/jobs/destroy_without_mgmtperms/with_permissions/out.destroy.direct.txt acceptance/bundle/resources/permissions/jobs/destroy_without_mgmtperms/with_permissions/out.destroy1.direct.txt renamed to acceptance/bundle/resources/permissions/jobs/destroy_without_mgmtperms/with_permissions/out.destroy.direct.txt

@@ -1,16 +1,12 @@
 
->>> musterr as-test-sp [CLI] bundle destroy --auto-approve
+>>> errcode as-test-sp [CLI] bundle destroy --auto-approve
 Warn: cannot read resources.jobs.foo id="[NUMID]": User [UUID] does not have View or Admin or Manage Run or Owner permissions on job [NUMID]
 Warn: cannot read resources.jobs.foo.permissions id="/jobs/[NUMID]": [UUID] does not have Manage permissions on Job with ID: ElasticJobId([NUMID]). Please contact the owner or an administrator for access.
 The following resources will be deleted:
   delete job foo
 
 All files and directories at the following location will be deleted: /Workspace/Users/[UUID]/.bundle/test-bundle-[UNIQUE_NAME]/default
 
-Error: cannot delete resources.jobs.foo: deleting id=[NUMID]: User [UUID] does not have Admin or Owner permissions on job [NUMID] (403 PERMISSION_DENIED)
-
-Endpoint: POST [DATABRICKS_URL]/api/2.2/jobs/delete
-HTTP Status: 403 Forbidden
-API error_code: PERMISSION_DENIED
-API message: User [UUID] does not have Admin or Owner permissions on job [NUMID]
-
+Warn: Ignoring permission error when deleting resources.jobs.foo id=[NUMID]: User [UUID] does not have Admin or Owner permissions on job [NUMID]
+Deleting files...
+Destroy complete!

…h_permissions/out.destroy2.terraform.txt …th_permissions/out.destroy.terraform.txtacceptance/bundle/resources/permissions/jobs/destroy_without_mgmtperms/with_permissions/out.destroy2.terraform.txt renamed to acceptance/bundle/resources/permissions/jobs/destroy_without_mgmtperms/with_permissions/out.destroy.terraform.txt acceptance/bundle/resources/permissions/jobs/destroy_without_mgmtperms/with_permissions/out.destroy2.terraform.txt renamed to acceptance/bundle/resources/permissions/jobs/destroy_without_mgmtperms/with_permissions/out.destroy.terraform.txt

@@ -15,10 +15,8 @@ job_id=$($CLI bundle summary --output json | jq -r '.resources.jobs.foo.id')
 
 trace $CLI permissions set jobs $job_id --json @take_ownership.json > /dev/null
 
-trace musterr as-test-sp $CLI bundle destroy --auto-approve &> out.destroy1.$DATABRICKS_BUNDLE_ENGINE.txt
-
 trace $CLI jobs delete $job_id
 trace musterr $CLI jobs get $job_id
 
 # This shows that even if job is deleted, you still get permission error when trying to delete it.
-trace errcode as-test-sp $CLI bundle destroy --auto-approve &> out.destroy2.$DATABRICKS_BUNDLE_ENGINE.txt
+trace errcode as-test-sp $CLI bundle destroy --auto-approve &> out.destroy.$DATABRICKS_BUNDLE_ENGINE.txt

acceptance/bundle/resources/permissions/jobs/destroy_without_mgmtperms/with_permissions/out.destroy1.terraform.txt

@@ -6,12 +6,6 @@ The following resources will be deleted:
 
 All files and directories at the following location will be deleted: /Workspace/Users/[UUID]/.bundle/test-bundle-[UNIQUE_NAME]/default
 
-Error: cannot delete resources.jobs.foo: deleting id=[NUMID]: User [UUID] does not have Admin or Owner permissions on job [NUMID] (403 PERMISSION_DENIED)
-
-Endpoint: POST [DATABRICKS_URL]/api/2.2/jobs/delete
-HTTP Status: 403 Forbidden
-API error_code: PERMISSION_DENIED
-API message: User [UUID] does not have Admin or Owner permissions on job [NUMID]
-
-
-Exit code: 1
+Warn: Ignoring permission error when deleting resources.jobs.foo id=[NUMID]: User [UUID] does not have Admin or Owner permissions on job [NUMID]
+Deleting files...
+Destroy complete!

acceptance/bundle/resources/permissions/jobs/destroy_without_mgmtperms/with_permissions/out.destroy2.direct.txt

@@ -15,10 +15,8 @@ job_id=$($CLI bundle summary --output json | jq -r '.resources.jobs.foo.id')
 
 trace $CLI permissions set jobs $job_id --json @take_ownership.json > /dev/null
 
-trace musterr as-test-sp $CLI bundle destroy --auto-approve &> out.destroy1.$DATABRICKS_BUNDLE_ENGINE.txt
-
 trace $CLI jobs delete $job_id
 trace musterr $CLI jobs get $job_id
 
 # This shows that even if job is deleted, you still get permission error when trying to delete it.
-trace errcode as-test-sp $CLI bundle destroy --auto-approve &> out.destroy2.$DATABRICKS_BUNDLE_ENGINE.txt
+trace errcode as-test-sp $CLI bundle destroy --auto-approve &> out.destroy.$DATABRICKS_BUNDLE_ENGINE.txt