Improve DB code - use iterators, transactions

[taniwallach]

For future work - improve DB code - use iterators, transactions

[drgrice1]

I did quite a bit of work on this in #1585. Note that iterators are not as good of an idea as was once believed. Iterators are more apt for obtaining large volumes of data, and the data that we deal with is nowhere near the threshold size needed to obtain the benefits of using them. For example, if you have a rather large class (say 5 or 6 thousand users) the amount of data needed to pull the entire class list is still less than 100 MBs (easily). That really isn't that big, and that is an extreme case. I actually have a class with more than 30,000 users and with the changes in #1585 there are considerable improvements to accessing the class list editor. I also tested with iterators on that course, and found there was no improvement from the way I ended up implementing it in #1585, in fact it seemed to be not as fast and the code is more convoluted.

The only table that gets that large is the past answer table, and we never access that all at once. I doubt iterators would be beneficial there either due to way that table is set up.

[taniwallach]

I think that I opened the issue based on things being discussed during a developer meeting to put it on the agenda. I suspect that #1585 probably addresses many of the real issues we had in mind when we wanted to create a reminder to work on the DB code.

Iterators: @drgrice1 has determined that at present there is no need to use them.

Transactions: I'm not familiar enough with the lower end DB code of WW to know to what extend implementing code to support suitable groups of operations on the DB being run as a transaction is feasible. My limited experience seems to hint that supporting transactions in webwork2 would probably require quite a bit of effort, as it seems the "regular" webwork2 code does not really have access to anything in the "low end" abstracted DB code to start/end a transaction or to "grab onto" a fixed DB handle which could be used to process all the operations of a transaction.

@drgrice1 @pstaabp It might be more feasible and valuable to see if transaction support can be provided in webwork3 early on using DBIx::Class support for transactions and not to try to retro-fit such support into webwork2. What do you think? If that makes sense to you, then this issue can be closed for webwork2.