Comment 9 for bug 1386347

One issue I've discovered with the change in when copy maps are deleted (captured vs. fulfilled), is that the queue position and # potential copies reported on capture holds now shows holds as being at the back of the line with zero potential copies. (I'll spare the details, but the crux is that w/o potential copies, the queue data gets thrown off).

Do we return to deleting copy maps when the hold is fulfilled instead of captured OR do we skip the queue calculation for captured holds and simply return position=0, potentials=1. The former is simple and returns the status quo, the latter produces different data, but allows for some efficiency (skipping queue calc).

Returning hard-coded queue values for capture holds is more honest in the sense that a captured hold really is at the front of the line, however we no longer have access to its queue position and # copies at the time of capture, without resetting (un-capturing) the hold, which is information staff may have relied on.