CloudVariables access controls

[gsteinLTU]

Close #1
Adds a setVariableAccess method where access levels can be set for other users with/without password. Old variables and variables created by logged-out users will default to all users with password having full access and without password having no access (except for unlocking a lock your client owns, although it shouldn't come up).

Remaining questions:

• Should the owner's access still be limited in any way? The old version did not have this limitation, but the owner always needs to have access to setVariableAccess so the password is kind of meaningless for them.
• Should the levels be additive (i.e. withPassword is a superset of withoutPassword)?

[gsteinLTU]

From today:

• Password should apply to owner to make testing functionality easier
• Access should be additive
• Should accept list of letters and list of level names
• Needs testing for when no password set
• Needs appendToUserVariable (and fix in documentation referring to "appendVariable")

[brollb]

Calling findOne then updateOne can be prone to concurrency bugs. I would use $push instead: https://www.mongodb.com/docs/manual/reference/operator/update/push/. (Then return an error if it fails.)

[gsteinLTU]

Thanks, I forgot they would be stored as actual lists in the DB

[gsteinLTU]

@brollb Something we didn't discuss that I just caught, should the _sendUpdate call when appending send the entire new list, or just the new value? Both seem like valid possibilities, but sending just the value appended is definitely simpler (and avoids bringing the concurrency issue back).

[brollb]

I would probably send the update with the entire list since there isn't currently a distinction between setVariable updates and appending updates. We should be able to use the findOneAndUpdate operation on MongoDB to avoid the concurrency issue.

[gsteinLTU]

Thanks, that will work.