implementation_status needs to allow for multiple values

[jbarnicle]

For some implementations, implementation_status can contain multiple values. Example: FedRamp controls could be both partially implemented and planned.

• Schema should accept implementation_statuses as an array of string in version 3.0.0
• Schema should accept implementation_status as a string in versions 2.0.0 and 3.0.0

[afeld]

Broken out from cloud-gov/cg-atlas#91 (comment).

[afeld]

@clovett3 or anyone else: Do you have a sense of whether having multiple implementation statuses for a particular control is FedRAMP-specific, or whether it's typical for controls in various system security plans?

@jbarnicle: I'd go with adding an implementation_statuses array field, as an alternate to implementation_status. Not sure if we should deprecate implementation_status, or support both. At the very least, using a new name will mean it isn't a breaking change to the schema.

[pburkholder]

This is a hard one. I'd prefer not to see schema sprawl, having to support implementation_status and implementation_statuses, but I don't think it makes sense either to say that implementation_status can be of type: any and let people use either string or seq as they need to.

Now that I'm done with dithering, I'd be okay with adding implementation_statuses and supporting both the list and scalar through version 4, and dropping support for implementation_status in version 5.

[afeld]

Things get more complicated in the parsing when the same field can be of different types, so would prefer to keep them under separate names. Means we can do this change as schema version 3.1, rather than 4.0.

[afeld]

@jbarnicle Game to add some acceptance criteria up top?