Record attribute indexing slowed by non-index configuration

EG 2.9+

A huge number of rows (700+) have been added to config.record_attr_definition in recent versions of Evergreen. However, most of these rows do not actually define any indexing at all, but are used for other purposes. The reingest process currently churns over all of these rows to ultimately do nothing.

One potentially easy win is to limit the group of attributes considered at ingest to only those which might index something. Quick testing indicates a substantial speed boost to typical use of metabib.reingest_record_attributes() (over 7x speedup).

WIP Branch is here:
http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dbwells/speed_up_rec_attr_ingest

working/user/dbwells/speed_up_rec_attr_ingest

One reason the above branch makes the difference is does is greatly reducing the number of resulting selects to config.coded_value_map. However, since the complete config rows also do these selects, additional speed may be realized by adding an index on ctype, such as:

CREATE INDEX ON config.coded_value_map (ctype);

This change in early testing cuts processing time by an additional ~15% over the branch above. Other indexes have been tried with diminishing returns, but these are still being investigated.

In addition, we should consider whether some of the newer config rows should in fact have 'filter' turned off in stock. The 'filter' attribute is true by default in the config.record_attr_definition, so intentions of recent commits are not 100% clear. I would advocate we set 'filter' to false for any row which has no indexing information (even though they are now caught by the branch commit above). We should also consider defaulting to false for some of the less common fixed fields, as it may be enough to now have them available for turning on if a site desires to do so.