List of test cases useful for verification of the work done on catalog zones (#261).

• When different labels hold the same PTR value (i.e., point to the same member zone), the catalog zone is broken and MUST NOT be processed (see Section 5.1).
  Test: Verify a zone occurs only once.
• A changed label may indicate that the state for a zone needs to be reset (see Section 5.6).
  Test: Verify a zone is reset if a label is changed (or document otherwise intended behavior).
• When a consumer of a catalog zone $OLDCATZ receives an update that adds or changes a coo property for a member zone in $OLDCATZ, it does not migrate the member zone immediately. The migration has to wait for an update of $NEWCATZ in which the member zone is present. Before the actual migration, the consumer MUST verify that the coo property pointing to $NEWCATZ is still present in $OLDCATZ.
  Test: Verify migration works as intended.
• Unless the member node label (i.e., ) for the member is the same in $NEWCATZ, all its associated state for a just migrated zone MUST be reset (see Section 5.6).
  Test: Verify the zone is not reset if the label stayed the same.
  Test: Verify the zone is reset if the label changed.
• The producer MAY assign a group property to all, some, or none of the member zones within a catalog zone. The producer MAY assign more than one group property to one member zone. This will make it possible to transfer group information for different consumer operators in a single catalog zone.
  Test: The group property should be mapped to patterns(?) Verify a zone has an implicit pattern if there's no group property or a group for which no pattern exists. Document how migration of a group property must work. We might need to add an alternate implicit marker for catalog zones to avoid clashes with existing patterns etc.
• Implementations SHOULD namespace their custom properties to limit risk of clashes with other implementations of catalog zones.
  Test: Verify we at least ignore custom properties that are not prefixed with nsd(?)
• If there is a clash between an existing zone's name (from either an existing member zone or an otherwise configured zone) and an incoming member zone's name (via transfer or update), the new instance of the zone MUST be ignored and an error SHOULD be logged.
  Test: Verify the implementation works as intended regarding clashes.
• When a previously correct catalog zone becomes a broken catalog zone, it loses its catalog meaning because of an update through an incremental transfer or otherwise. No special processing occurs. Member zones previously configured by this catalog MUST NOT be removed or reconfigured in any way.
  Test: Verify behavior is correct with regard to zones becoming broken.