Ordered tag comparisons result in spurious diff reports

[rainest]

Originally reported internally in Jira ticket FTI-2097. tl;dr deck thinks tag order matters and tries to act on it. Tag order doesn't actually matter, and deck shouldn't do that.

Assume you have a service whose tags are [foo,bar]. When dumping configuration using --select-tag foo, deck stores the resulting dump with something like the following:

_format_version: "1.1"
_info:
  select_tags:
  - foo
services:
- host: example.com
  name: example
  ...
  tags:
  - bar

Although the selected tag is present on the object, it isn't shown directly in the object itself, only in the _info block. When syncing, tag information is rebuilt, and tags are added to internal Go structures in some specific order. This order does not necessarily match the order reported by the admin API on Cassandra-backed nodes for an unknown reason (I did not investigate to see exactly how deck and Cassandra build the tag set to determine why this happens, but observed that it did happen with the provided customer data).

Because deck represents the tag set internally with an ordered slice, this order change can result in a reported difference when we compare the target object (from the dump YAML) to the current object (from the admin API). This difference in the Go structures does not correspond to an actual difference, however: the tags associated with a Kong object are sets, and their order is only an artifact of the YAML or JSON arrays we use to display them.

Although the apparent difference has no logical impact on the object, deck perceives one, and will attempt to update or create it (depending on whether or not you ignore IDs, I think). This either results in unnecessary requests or a failure (attempting to create a new object with the "correct" tag order will usually result in a uniqueness conflict).

Although the example code here is for services, this can affect any taggable entity (i.e. most entities).