Provide symfony event dispatcher events for all older hook types

[PVince81]

1. The very old static hooks: \OCP\Util::connectHook()
2. The less old object based emitters: keyword BasicEmitter where you listen directly on objects
3. The newer way we want to go for everything in the future: Symfony event dispatcher listeners

For every hook of type 1) and 2), we should provide a Symfony event dispatcher event.

Then all app development needs to use only the Symfony event dispatcher ones in the future and those will be considered public API and the old ones deprecated.

[PVince81]

cc @DeepDiver1975

[gruentee]

Yes, please!

[sharidas]

Here is my observation with replacing old hooks with symfony event dispatcher. I landed up with the troubles due to my faulty assumption of "simply replace", which wasn't simple. I replaced copy, rename, create update hooks with event dispatcher. And it wasn't easy to update the unit tests. I landed up a situation where for a move or rename operation, the actual listener for a post_rename event should have been https://github.com/owncloud/core/blob/master/lib/private/Files/Node/HookConnector.php#L67. Where as in my case the same event name was listened by https://github.com/owncloud/core/blob/master/apps/files_sharing/lib/Helper.php#L41. To be honest I haven't tried playing with priorities to symfony events. Without having deeper understanding of how older hooks work, I guess its not going to be an easy task.

[PVince81]

and then we had a chat and clarified that we don't want to replace the old hooks right now because of potential nightmare-issue with core using these. The next step is to first add new symfony events that will be fired just after the old hook ones. The old hooks stay untouched.

[PVince81]

Once the Symfony events are in place, this would be the next step: #29672

[sharidas]

1. The usage of fileinfo in the events, looks bad because if there are no listeners for the event then it would again affect the performance because fileinfo is no longer used.
2. The usage of sending View object and paths as custom symfony event, the main problem here is view becomes public. Not a good idea
3. The usage of sending just paths. Looks kind of ok. The paths received by the subscriber can use the Node API to get the file id. That becomes little more expensive if there are more apps which use the events to get the file id.

[PVince81]

So far I only see 3 as a viable solution: basically just pass the path like the old hooks did and let the listener do \OC::$server->getUserFolder()->get($path) to get the node and file info. The latter operation can be expensive especially if repeated in multiple places. Getting the fileinfo hits the database every time. There is a potential solution for this here: #28260