Drive: remove costly and unnecessary calls to hasPermission in FileSystemItem adaptation

Release Notes

Permisison check has been optimized when adapting a document as a FileSystemItem for the Nuxeo Drive synchronization.

Technical details

JVM sampling during a call to GetChildren shows that DefaultFileSystemItemFactory#adaptDocument spends a lot of time in CoreSession#hasPermission.

Attached visualvm snapshot shows that on a call with 1.000 children approximatively 2500 ms come from hasPermission.
Yet in this cases the slowness may come partly from security since there are lots of aclr cache: ~4000 aclr per user.

Currently there are 3 occurrences of hasPermission in AbstractDocumentBackedFileSystemItem:

    protected AbstractDocumentBackedFileSystemItem(String factoryName, FolderItem parentItem, DocumentModel doc,
            boolean relaxSyncRootConstraint) {
        ...
        canRename = !doc.hasFacet(FacetNames.PUBLISH_SPACE) && !doc.isProxy()
                && docSession.hasPermission(doc.getRef(), SecurityConstants.WRITE_PROPERTIES);
        DocumentRef parentRef = doc.getParentRef();
        canDelete = !doc.hasFacet(FacetNames.PUBLISH_SPACE) && !doc.isProxy()
                && docSession.hasPermission(doc.getRef(), SecurityConstants.REMOVE)
                && (parentRef == null || docSession.hasPermission(parentRef, SecurityConstants.REMOVE_CHILDREN));
        ...
    }

We can probably remove the check on REMOVE_CHILDREN since:

• Having REMOVE on a child and not REMOVE_CHILDREN on the parent is unlikely.
• These flags are used by Drive to prevent making a call that would fail in case of permission not granted but if the call is done anyway it will result in a 500 error handled by Drive. And when the call is done, even if the flag was indicating a granted permission, there is no guarantee that the permission wouldn't have changed just before that.

And one occurrence in DocumentBackedFolderItem:

    protected void initialize(DocumentModel doc) {
        this.name = docTitle;
        this.folder = true;
        this.canCreateChild = !doc.hasFacet(FacetNames.PUBLISH_SPACE)
                && doc.getCoreSession().hasPermission(doc.getRef(), SecurityConstants.ADD_CHILDREN);
        this.canGetDescendants = true;
    }

We can probably consider that being granted WRITE_PROPERTIES means being granted ADD_CHILDREN, so use canRename here.