BibSort main goal is to make the sorting of search results faster.
It does this by creating several buckets that are then loaded by
the search_engine and cached.

This is what happens per sorting method (which can be either
a ranking method or a sorting field/list of MARC tags):

    I. Rebalancing the buckets (reconstructing the buckets):
	- (1) the data for all the records is loaded into a dictionary
	- (2) based on the washer method (if any is defined in the
		cfg file) date is adjusted (dates normalized, removing
		leading articles..)
	- (3) the data dictionary (containing recid:value) is then
		sorted based on values
	- (4) after the sorting, each record receives a weight (it can
		be the index in the sorted list or a multiple of the index)
	- (5) based on the sorted list of recids, the buckets are created,
		by splitting this list in CFG_BIBSORT_BUCKETS parts
	- (6) the maximum weight per bucket will also be stored in
		the database, along with each bucket
	- (7) everything is stored in the database

    II. Updating the buckets (can run each 5 min, to update
	the buckets with the latest changes. Probably it would be best
	to run it after BibIndex, in order for the user to see the new
	changes as soon as they are indexed)
	- (1) detect which methods should be updated: either
		ranking - from rnkMETHOD tables, either usual sorting
		(by field or MARC)
	- (1i) if RNK method -> then run rebalancing, since anyway,
		we have to read all the data for all the record
		(check also if the method needs to be deleted
		rather then updated) - END
	- (1ii) if sort by field -> detect which recids have been
		modified since the last run of bibsort
	- (2) based on the washer method (if any is defined in
		the cfg file) date is adjusted (dates normalized,
		removing leading articles..)
	- (3) compute the records that need to be inserted, modified and
		deleted (with the help of the data dictionary (see I.2)
		that is loaded from db)
	- (3i) insert: new recids with their values will be inserted into
		the data dictionary; binary search will be used to compute
		the index of the new record in the sorted list of records;
		a new weight will be given to this record based on this index
		and on the weights of its neighbours (ex: recid 3 needs to be
		inserted between recid1-weight=4 and recid2: weight=8 =>
		recid3 will have weight=6); initially, the weights are given
		as such that there are free weights between any 2 recids;
		when these spaces are filled, the weights will be recomputed,
		to recreate spaces between them.)
	- (3ii) delete: the recids will be deleted from all the data structures
		(except the buckets, since there is no actual need for that,
		the intersection with the search_engine output will guarantee
		that the record will  not be displayed)
	- (3iii) modify: combination between insert and delete
	- (4) update the buckets to reflect the latest changes; here, we will
		take advantage of the maximum weight per bucket = the highest
		weight value per bucket (I.6); since the buckets are not ordered
		(are intbitsets, for taking advantage of fast intersections)
		we will add the new records based on their weight (the main idea
		is to compare the weight of the modified records with the max weight
		and decide in which bucket to be added/deleted.