Create lock and unlock endpoints

[cleberjamaral]

Lock and unlock will be used to notify other developers that some file is being edited by someone. The first basic version could be just for "models", i.e., not aware of specific agent of artefact instances. Indeed, jacamo-web still has limitation about editing agents in which the .asl has a name different from name_of_agent.asl.

The endpoints must have the filename of the referred file, like these: /lock/{filename} /unlock/{filename}

format: const lock = { file1: ['user1', 'user2'], file1: ['user3', 'user4'] }

[cleberjamaral]

/lock and /unlock end-points are sharing a list of locked resources. To help to check if the same user is already using a given resource it is possible to add him multiple times, i.e., the list of users per resource may have duplicated elements. IMPORTANT: in a few tests it was possible to produce fails on the current locking system. I think to prevent problems it would be necessary to implement a more sophisticated session control system which will take more time.

[cleberjamaral]

Using the websocket end-point /ws/message it is possible to receive from all opened sessions messages telling that some user just locked or unlocked some resource.

Later, a similar logic can be applied to some user that is editing a specific resource be notified that he needs to be aware of some understandability or usefulness issue. In these cases, it is better to improve ws to support more endpoints. It could be created for instance /ws/resource/{ressourcename} where the developer that is editing the given resource should subscribe and other developers that may be generating warning regarding that resource, can put messages to be pushed to the interested party.