Register new schema independently from changing other properties
Register new schema independently from changing other properties

The only way to update a schema so far has been to call `PUT
/event-types/{name}` with the complete definition of the event type in
the body (including the modified schema).

This way of changing schemas has proven to be problematic, as users
could accidentally modify other properties of the event type when
their intention would be to only change the schema.

One example in particular has been causing a lot of problems:
automated schema evolution performed by Nakadi SQL.

Nakadi SQL listens to schema changes made to input event types of
queries and automatically reflects those changes in the schema of the
output event type. It then calls `PUT /event-types/{name}` with the
new schema in order to register it. But this call fails due to
something unrelated to the schema change: the authorization section.

Every time an event type update is performed, all the properties are
validated, including authorization. But when users leave the company,
their identifiers are no longer valid, meaning that updating updating
event types fail if they are not removed from the event type
definition.

We consider that removing users from the authorization section is
responsibility of the team owning the event type and not job of an
automated task related with schema updating. So we are decoupling both
changes in order to solve the problem of automated schema change
independetly from maintaining an up-to-date authorization section.

zalando/nakadi,zalando/nakadi