Optimize queries for Components listing

[uberbrady]

A customer reported that listing large numbers of components seemed to cause error 500's from the API endpoint. Taking a quick look through debugbar, it seems like we were trying to load every asset associated with every component on the page, which I can easily imagine exhausting memory.

This change removes those with() entries, and uses the withSum() Eloquent method to make the database dynamically calculate those counts for us, and modifies the numCheckedOut() method to try to use that value if it exists - or to dynamically calculate it if it doesn't. And that dynamic calculation had been working on the 'Collection' object, rather than the database, so this adds the () to the relationship to make it a DB-level calculation rather than loading up all of the related objects and summing up through that collection.

The challenge here is that, because that value is now cached, if you were doing something with components and checking the value of that numCheckedOut() value when it should have changed, it will stay the same due to the caching.

I looked through the code and it doesn't look like we do that anywhere. Still, just in case, I added a new optional parameter to numCheckedOut() - which defaults to false - that will force it to recalculate the result and save that to the cache.

Another thing I did was reduce the number of times we called components->count() by throwing the result into a variable.

Tests

Tests do pass, and I did a make sure that the components index page loads correctly and displays the right values.