Discussion: allowing additional properties in assigner config schemas

[LinuxMercedes]

From https://github.com/redkyn/assigner/pull/146#issuecomment-656253058:

We need to bump the Assigner config version as previous versions of Assigner fail to validate a config with a "canvas-courses" key in it. I am now inclined to allow additional properties to permit semi-backwards-compatibility, but I can't recall if we had a good reason for disallowing them in the past.

The PR spurring this discussion adds a new key to Assigner's config, but does not change the semantics of the existing config entries and gracefully handles the situation where such a key is not present. If we permitted additional properties, this PR would not require a schema version bump, but as we don't, it does.

Since the issue of whether we keep additionalProperties = False in the next Assigner schema is independent of that PR, I figured it'd make sense to move the discussion to a separate issue.

[LinuxMercedes]

My thought is that additionalProperties = False made sense before we got versioned config schemas, as it served as a crude warning that you probably needed to update Assigner as the config semantics might have changed. Now that we have versioned schemas, and thus can explicitly state a semantics change by updating the version number, I am of two minds:

1) We can have little a additional properties, as a treat, provided:

• Existing versions of Assigner read and save the additional properties without modifying them when saving configs.
• No additions to the current schema's upgrade function are necessary. I think the particular situation of PR 146 would meet both these criteria. 2) The point of config versioning is to keep all the config key edge case handling in one place and out of the way:
• Most any graceful error handling is going to require something like https://github.com/redkyn/assigner/blob/master/assigner/config/__init__.py#L59-L61, which I believe is there merely for backwards compatibility with very old configs, and might even be removable now. See, for example, https://github.com/joshessman/assigner/blob/c4fc7adde5f3c71ce4020846390ad588d6918b90/assigner/config/__init__.py#L63-L65
• It feels wrong for two versions of Assigner to have disagreeing copies of the same schema version. This theoretically leads to a situation where Assigner v2.0.0 validates a version 2 schema but Assigner v3.0.0 does not. Admittedly that's quite a theoretical concern as that should only happen for development versions where all bets are off anyway :)

@brhoades, tell me I'm wrong (you can't not do it)!

[LinuxMercedes]

Another argument for not allowing additional properties:

• With additonalProperties = False, if you edit your schema and mess it up or put in something Assigner doesn't recognize, you get an error message and Assigner gives up.
• With additionalProperties = True, if you make a typo, Assigner may not show you an error and thus behave "weirdly", and if you stick extra stuff in, there's a chance a future version of Assigner will clobber that extra stuff silently.