Delete public links on GET

[refs]

Following up on #1361

Due to tunnel vision and solving one single problem, public links get deleted now on ListPublicLinks operations, but as long as we don't have background jobs they MUST also be deleted on GetPublicLink operations.

There is the scenario that a public link is expired but ListPublicLink has not run, accessing a technically expired public link is still possible.

A proposed solution is deleting the link on access.

[update-docs]

Thanks for opening this pull request! The maintainers of this repository would appreciate it if you would create a changelog item based on your changes.

[labkode]

@refs we can easily add a goroutine to the json manager to clean the links without having to do it on these ops?

[refs]

@refs we can easily add a goroutine to the json manager to clean the links without having to do it on these ops?

and run launch it on every operation?

[labkode]

@refs when the driver is started as part of the init process for example.

[refs]

@refs when the driver is started as part of the init process for example.

The only drawback I see with it is the number of unnecessary cycles that routine would do just checking whether a share is expired or not, then since we're polling the db, that also needs to work with the locks, I see that even using RWMutex won't help much since we'd need to take a write lock on the mutex.

Now even if we got the goroutine blocked polling the json "db" for expired shares there could still be the case that a share is expired the moment it's accessed or listed, this is the argument that drove me to go with this "delete on-demand" approach.

Let me spend some time using time.AfterFunc and see how far I get

[refs]

@labkode have a look at 5c3c7be (#1364) if you can and share your thoughts.

The abstraction was done due to the init() being called multiple times it is impossible to synchronize every call without introducing yet more global state. Instead of adding that logic in the init() method I'd rather do it in the constructor because it's called only once.

There is no way to provide a logger since the manager has no awareness of service configuration, so at the moment the janitor is silent and runs by default every 10 seconds (this needs to be configurable).

I have not measured the performance impact of this nor with a small sample db or a large one, so the costs of locking, serializing, iterating and removing are not being accounted for, only functionality.

[refs]

A small remark to add is that even with this janitor logic I'd still like to leave the on-demand checks on each method to avoid stale data.

[refs]

ping @labkode