`setupForPath` does too much work

Description

Currently setupForPath suffers from a few issues that make it less efficient than it could be.

1. Setting up the same path over and over loads the mount information from the DB
2. It is affected by N+1 issue if code ends up calling setupForPath on every item of a directory
3. Paths that do not contain mounts are currently not tracked, so when this happens we get the effects of 1 (wasted CPU cycles)

Update: seems that the only real issue to solve is # 2

Details

1 - Repeated queries to oc_mounts

This could be easily fixed: when a path is set up and we find a mount, the path is marked as set up with or without children. We can use this information in the next call by either skipping the query entirely if the setup would not end up loading more data than was already done.

Update: this does not perform a DB query as we load all rows from oc_mounts and cache them in memory. So the only thing that this causes is some wasted CPU cycles.

2 - N+1 issue

This issue can potentially come by any code path that uses code calling setupForPath and does this for every item in a directory.

I can think of two solutions, that are not mutually exclusive.

• Solution A: find affected code (e.g. ShareAPIController) and call setupForPath with the appropriate parameters. We may still miss cases though.
• Solution B: SetupManager could count how many times setupForPath is triggered for children of a directory and once a threshold is reached, trigger a setup for the parent with $withChildren = true.

3 - Setup calls for paths without mounts are not tracked

Since we are caching the information that a path was set up using the mount point, only paths with a mount point can currently be optimised.