Improve relation choices limiting (using html_cutoff)

[blag]

When we're showing the HTML form field for related objects and we're trying to generate the choices for the select field, it doesn't seem to make sense to grab every single record in a table, only to display html_cutoff (default: 1000) of them and completely ignore the rest.

Instead, we should limit the number of objects we want from the database to the number of objects we're planning on displaying. This changeset makes the semantics of retrieving related objects the same as for displaying related objects. In other words, we limit the queryset to the first html_cutoff objects. That way we aren't pulling back more objects than necessary, because this can kill performance for tables with "lots" of records (~500k in my case, ~400k for others).

Closes #3329.

[tomchristie]

Worth double checking where we use choices. The use of html cutoff was explicitly intended to limit the slicing to just HTML, but it probably is worthwhile adopting this change and using the cutoff throughout (perhaps considering a naming change along the way) but are we using .choices as part of the validation itself? Is there any chance this could cause a behavioral change for any existing APIs?

[blag]

Sorry I haven't gotten back to this yet, I've had other stuff I needed to do.

I'll go through the codebase (hopefully tonight) and check out where choices is used.

Regarding the name change, I'm thinking something like db_cutoff. Thoughts/suggestions?