Fix share key finding algorithm in various cases

Instead of inaccurate pattern matching, use the list of users who we
know have access to the file to build the list of share keys.

This covers the following cases:

- Move/copy files into a subfolder within a share
- Unsharing from a user
- Deleting files directlry / moving share keys to trashbin

Conflicts:
	apps/files_encryption/lib/keymanager.php
	apps/files_encryption/tests/hooks.php
	apps/files_encryption/tests/keymanager.php
	apps/files_encryption/tests/trashbin.php
Removed broken/unneeded fixFileSize

fixFileSize is not needed as the target file will already have the
correct unencrypted size after renaming
Remove FileInfo instance check

FileInfo class doesn't exist in stable6
Disabled assert known to fail

stable6 has a bug where the share keys are not properly deleted when
deleting a shared file as non-owner.

To make sure the more important fix from the backport of
1e631754d78e98d74ba0d3fb477d5eb815e9dfb3 can be applied, the
corresponding assert introduced by the backport is disabled.
Merge pull request #11560 from owncloud/stable6-encsharekeymatchingdirectbackport

[stable6] backport share key pattern matching fix