Feature : Handle portal's entities

[mmorel-35]

The same way others entities of the gateway are handled by deck we should be able to handle the portal's entities : developers and developer's roles.
There could be a flag --portal-only to ensure to allow separation of concern between gateway and portal's entities. They're not incompatible of course, but portal's entities doesn't support tags so it cannot be used with select-tag option

[rainest]

Developers further present an additional challenge: when you create a developer, you provide fields (e.g. password) that are not visible on the final object. Thus, with a naive approach, if you perform an initial sync and then an additional sync after using the same state file, deck will detect a diff and send a PATCH to try and set the "missing" fields. Unsure if that request can actually succeed (Kong ignores the fields and returns a 200) or not (Kong rejects the problem fields and returns a 400).

This requires either that you manually dump state after developer creation and use that as a basis for subsequent syncs (which is quite inconvenient) or that deck's diff logic be aware of the problem fields and handle them gracefully.

[mmorel-35]

In my use cases I manage developers with basic and openid-connect authentication.
In none of those cases I want to know the password of those developers.
I copy the mail, custom_id, rôles and full name (meta) of the developers between instances of kong.

On the first synchronization the password is used to create the developer.
What I did to copy basic-auth users is to generate a random password on the deck-like file that contains the list of the developers. The openid-connect developers didn't required it as it is handled by the IDP. The basic-auth users will of course have to renew their password.
On the second synchronization the diff tool can ignore the rbac user, the consumer, the timestamps because they don't matter to the user. The password can be ignored because it belongs to the developer himself.
What do you think?