Add `LINK` and `UNLINK`

[fwcd]

Would be nice to have those operations

[NicoBiernat]

I am thinking about removing those operations from beacon or changing their behavior.
They seem very nice to have but also make other things much more complicated.
For example:

• Ensure that links don't form a cycle and forward data indefinitely (this is already implemented with depth-first-search)
• How to list and display all current links? (they are a set of trees on the same set of nodes as the hierarchical directory tree)
• How to save and restore all links in case of a restart? (currently all links are deleted because the savepoint only stores the main directory and its contents)
• How to ensure not to accidentally link two image streams to the same output and get epilepsy inducing flickering?

Some problems can be solved for example by just listing and storing links in a list of pairs [ (source, destination) ].

But we might have to discuss if we really need links.
The reasons for links that come to mind would be:

• link some user to the live display (we already found an alternative solution)
• to mirror someones display
• merge different user's input events to handle them (e.g. for a multiplayer game) -> could just stream multiple resources

An alternative for links as they are implemented right now could be symbolic links like we use for the lamp-server (LaSer) to show different users:
Every user has a [user, username, link] resource which contains either nothing (nil) or a path to another resource.
If someone GETs or STREAMs this resource, we first check if the link resource contains a valid path.
If this is the case, we return that resource instead. Else we continue normally with the users resource.
LINK and UNLINK then only write to the link resource.
We still need to ensure that there are no cycles in the links.
Also we have to think about what PUT/POST does in the case of a link.
Links are automatically saved (they are just normal resources).

If we decide to remove LINK and UNLINK, they should be removed from the library.
If we decide to change the behavior, I will not change the API for LINK and UNLINK.

[fwcd]

I believe we should move that discussion to beacon and then update the libraries accordingly.

[NicoBiernat]

But I'm the only one working on beacon, so I wanted to discuss this with you 😆
Maybe it's a topic for our meeting 😄