fix(rbac) include Negative when marshaling RBAC

[rainest]

The custom JSON marshalers for these types omitted the Negative field, which prevented decK (or any other user of go-kong) from applying it. This was originally reported internally in FTI-2405. To recap/demonstrate, repeated syncs of negative.yaml.txt would not never actually sync a negative permission, since the PATCH omitted that field:

./deck sync -s negative.yaml --rbac-resources-only --verbose 2
{"next":null,"data":[{"endpoint":"\/acls","created_at":1617146918,"workspace":"default","actions":["delete","create","update","read"],"negative":false,"comment":null,"role":{"id":"bb1522dc-e323-456a-bb9d-1d5f3fd07f6d"}}]}
updating rbac-endpointpermission bb1522dc-e323-456a-bb9d-1d5f3fd07f6d-default-/acls  {
   "actions": "delete,create,update,read",
   "endpoint": "/acls",
   "workspace": "default"
 }

PATCH /rbac/roles/bb1522dc-e323-456a-bb9d-1d5f3fd07f6d/endpoints/default//acls HTTP/1.1
{"workspace":"default","endpoint":"/acls","actions":"delete,create,update,read"}
HTTP/1.1 200 OK

{"endpoint":"\/acls","created_at":1617146918,"workspace":"default","actions":["delete","create","update","read"],"negative":false,"role":{"id":"bb1522dc-e323-456a-bb9d-1d5f3fd07f6d"}}
Summary:
  Created: 0
  Updated: 1
  Deleted: 0

With this change to go-kong, the PATCH will include that field, and the permissions will honor the negative field in the state file.

[shaneutt]

👏

[mflendrich]

json:"..." tags on the definitions of structs that have a custom marshaler are very confusing, and pointless if there's a custom marshaler that defines its own representation unrelated to those tags.

The best (yet breaking) solution here to avoid this problem from happening in the future would be to make Actions a custom type with its own custom marshaler, and leaving the types including Actions with a default marshaler. But, as I said earlier, this is a breaking change so probably a no-go at this moment. Also I would rather not remove tags because of potential unexpected side effects.

The second best improvement I can think of is adding a warning comment on those types (that, despite tags, the default marshaler is not in use.

Therefore, here's my optional (yet strongly recommended) action item: on types that define a custom marshaler and have json tags defined, put a warning comment like:

// Note that this type implements a custom json.Marshaler and json.Unmarshaler!