marathon.ces.unit/has-state? fails when checking for a keyword

[fs-tom]

We get an invalid result of false for

(marathon.ces.unit/has-state? {:statedata {:curstate #{:unavailable :waiting}}} :waiting)

due to the ``has?``` implementation.

We should be detecting that the state is a set and dispatching accordingly, but it seems we have a hole in our conditional logic. This manifests for the RC_Cannibalization rule, which includes a #{:unavailable :waiting} state set vs. the prior :waiting state keyword. It should fail for any set-based states we use, triggering errors like attempted policy changes during state sets that include waiting.

[fs-tom]

Looks like it affects a couple of checks in marathon.ces.unit, namely:

deployed?, recovering?, demobilizing?, and can-non-bog?

However, these checks previously were only being fed keyword states (e.g. the merged :statedata from the :wait-state information was a single keyword, also the policy information for the aforementioned was always a single keyword (as opposed to dwelling states, which tended to be compound sets). Looks fairly contained as a result.

[fs-tom]

fixed in 7f23d233c398e34a077dbd92c6d36164e3ad3d1e