SqlPackage needlessly re-grants, or revokes-then-grants, permissions on types

- SqlPackage or DacFx Version: 170.1.61.1 (and the latest version of Visual Studio 2022)
- .NET Framework (Windows-only) or .NET Core: Not applicable.
- Environment (local platform and source/target platforms): Windows 11, SQL Server 2016.

**Steps to Reproduce:**

A repro can be found here: https://github.com/DanielLoth/sqlpackage-bug-repro-2

1. For the `Example1` project, first deploy with `CreateNew.publish.xml` and then deploy a second time with `Changes.publish.xml`.
- Key observations:
- The generated change script contains **no** T-SQL statements.
- It does not erroneously attempt modify a permission.
2. For the `Example2` project, first deploy with `CreateNew.publish.xml` and then deploy a second time with `Changes.publish.xml`.
- Key observations:
- The generated script contains T-SQL statements that modify permissions grants.
- The permissions in question, having already been applied in the first publish of the database, should not be modified during the second publish.

These are the statements that are generated on the second and subsequent publish operation for `Example2`:

```
REVOKE EXECUTE
ON TYPE::[MySchema].[MyTypeGrantWithAuthorizer] TO [MyRole] CASCADE;
GO
GRANT EXECUTE
ON TYPE::[MySchema].[MyTypeGrantWithAuthorizer] TO [MyRole]
AS [MyUser];
GO
GRANT EXECUTE
ON TYPE::[MySchema].[MyType] TO [MyRole];
```

This is the schema definition for `MySchema` within `Example2`:
```
create schema MySchema authorization MyUser;
go
```

The following is the corresponding `model.xml` file extracted from the DACPAC file:
```

```

This is the `model.xml` excerpt for the `MySchema` schema. We see that the non-`dbo` authorizer is correctly specified here (i.e., `MyUser` will be the owner of this schema, not `dbo`).
```

```

However, here's the excerpt for the permission grant that is performed _without_ specifying an authorizer - and we can see that, for some reason, the `Name` contains `[dbo]` where you might reasonably expect it to contain `[MyUser]:
```

```

In other words, I believe that this:
```
[Grant.Execute.Type].[MyRole].[dbo].[MySchema].[MyType]
```

Should instead have been this:
```
[Grant.Execute.Type].[MyRole].[MyUser].[MySchema].[MyType]
```

With the rationale being that `dbo` - which does not own `MySchema` (which is actually owned by `MyUser`) - can't actually grant that permission. In fact, if you explicitly specified `dbo` as the grantor then the T-SQL statement would produce an error (because it doesn't own the secured object.

For example, this:
```
use [SqlPackageRepro2-Example2];
go

GRANT EXECUTE
ON TYPE::[MySchema].[MyTypeGrantWithAuthorizer] TO [MyRole]
AS [dbo];
```

Results in the following error message:
```
Msg 15151, Level 16, State 1, Line 4
Cannot find the type 'MyTypeGrantWithAuthorizer', because it does not exist or you do not have permission.
```

The second one is a little more baffling unfortunately, and it's less clear why this leads first to the `REVOKE EXECUTE ... CASCADE` followed by the `GRANT EXECUTE ... AS MyUser`:
```

```

Anyway, you might have a better idea than me when it comes to exactly why this is happening.

**Did this occur in prior versions? If not - which version(s) did it work in?**

Yes.

(DacFx/SqlPackage/SSMS/Azure Data Studio)

---

Thank you for taking the time to read this bug report.

Kind regards,
Daniel Loth

Start with the linked sqlpackage-bug-repro-2 repository, deploying Example1 and Example2 with CreateNew.publish.xml and Changes.publish.xml. Inspect the generated scripts and the supplied model.xml permission elements, especially the grantor names for MySchema types. Done means repeated publishes produce no unnecessary permission changes and valid grants do not generate erroneous revoke/grant operations.

Written by the indexing model from the issue text.