Manage lock

[BECATRUE]

Feature you want to implement

To manage WLM safely, introduction of lock is necessary.

A lock is offered to each user, and the same team member is able to release it.
To prevent the lock for unlocking due to unexpected client issues, clients should request to extend the locks before their expiration.

What I won't implement in this issue is as follows.

• Wait until acquiring the lock.
• Lock expiration. It means that the lock will persist unless it is manually released.
• Release the team member's lock.

How the feature is implemented

Offer the lock status with channel info (POST/channel/)

• To initialize UI, the current lock status for the user is necessary.
• The lock status would be added to the channel info serializer.

Consumer for offering the lock status in real-time

• Whenever the lock is acquired or released, its status would be offered to all users following the channel through WebSocket.

Try to acquire the lock (GET /lock/<int:ch>/try/)

• It returns whether the user acquires the lock immediately.

Extend the lock (PUT /lock/<int:ch>/extend/ (NOT HANDLED)

• It extends the lock.

Release the lock (PUT /lock/<int:ch>/release/

• It releases the lock.

Check the lock expiration (NOT HANDLED)

• The server checks if the lock is expired and if so, it releases the lock.
• To reserve this, I will utilize Celery library.

When updating a setting, check the lock status

• Whenever a user requests for updating a setting, the server verifies if the user has a valid lock or the channel is free.

Additional context

I'm not sure there is no racing condition... However, I'd like to postpone this after v1.0.0.

[BECATRUE]

I think we can consider two types of locks.

1. Lock for all channels of the team

The user holding the lock has full privileges for all channels belonging to the team.
The other users cannot update the exposure time or period, nor can they start or stop measurements on any channel.
However, they can forcibly release the lock.

2. Lock for each channel of the team

The user holding the lock has full privileges for the specific channel belonging to the team.
The other users cannot update the exposure time or period, nor can they start or stop measurements on the locked channel.
However, they can control other channels and acquire the locks of them, in addition, can forcibly release the lock.

In addition, we should consider how to handle the locks of channels belonging to the multiple teams.

In my opinion, I find the second one better, but what do you think? @kangz12345

[BECATRUE]

As we discussed, I adopted the second one and will allow a channel belonging to multiple teams to be locked.