Polaris management API spec improvements

[snazy]

Describe the bug

The current Polaris management spec has a few shortcomings:

• It exposes and requires persistence internals (Remove entityVersion from public APIs #556) like entityVersion, created/modified timestamps
• It exposes the rather internal persistence model via a public API
• None of the list requests/responses are use paging
• It uses the generic property bags, which requires detailed knowledge of the properties on each client (Replace "property bags" in polaris-management-service.yml with specific attributes #555)
• Create/update/delete requests rely on persistence internals and changes are improperly validated on the server side

I propose a complete overhaul of that API, as a v2 and eventually remove v1 before 1.0:

• Enable pagination of list requests using opaque paging-tokens
• Have a data model built on actual, distinct properties instead of generic property bags. This helps users to reason about individual properties and also helps to not accidentally exposing sensitive information.
• Have specific update requests (or update request payloads) for each kind of change instead of sending the whole entity and update everything. This is much easier to reason about from the client side and also much easier to verify & validate on the server side.

To Reproduce

No response

Actual Behavior

No response

Expected Behavior

No response

Additional context

No response

System information

No response