[COL-333] Return value of a lock not it's reference

[dpiatek]

https://ably.atlassian.net/browse/COL-333

When a lock is retrieved by using locks.get, a reference to an object is returned. By mutating this reference, a developer, could in theory, mutate the lock held by Spaces. This could lead to subtle and hard to debug issues.

This commit changes the .get and .getAll methods to return copies of objects instead. This breaks some of the internal mutations, so they are replaced by the already present .setLock method which will override the lock with a new object, severing any dependecies on references.

[lawrence-forooghian]

It's not clear to me what exactly is the scope of this PR. My reading of COL-333 is that it's about making sure we return all objects to users by value. This PR seems to only address the locks functionality. Is that intentional?

My review of this PR is going to be a bit superficial because I don't yet know enough about the codebase. But, looking at the Locks.ts code, it seems like:

• getSelf() still returns the lock object by reference
• the first part of processPresenceMessage (handling LEAVE presence event) emits a lock object by reference

[dpiatek]

It's not clear to me what exactly is the scope of this PR. My reading of COL-333 is that it's about making sure we return all objects to users by value. This PR seems to only address the locks functionality. Is that intentional?

My review of this PR is going to be a bit superficial because I don't yet know enough about the codebase. But, looking at the Locks.ts code, it seems like:

• getSelf() still returns the lock object by reference
• the first part of processPresenceMessage (handling LEAVE presence event) emits a lock object by reference

hey @lawrence-forooghian - in terms of scope, the ticket was written when most classes had some API that returned a reference, that is no longer true. Only Locks return references now, all other classes generally use the presence set, map over it and return new objects.

getSelf() still returns the lock object by reference

that's my bad, missed updating getLocksForConnectionId - will fix

the first part of processPresenceMessage (handling LEAVE presence event) emits a lock object by reference

was thinking it does't matter because the locks are deleted straight after, but I guess it's better to be consistent here. will fix