Support filtering annotations by page number or range

[robertknight]

Support page:{number} or page:{start}-{end} filters in the sidebar. When the query is a number, it must match the page label exactly. When it is a range, it matches the page number if:

• The start and end of the range, and page number, are all numeric
• The page number is between the parsed start and end points, inclusive

In the context of VitalSource assignments with page numbers, the plan is that this filtering will be used as part of a "focus on pages in range X-Y", which will be implemented internally similar to the way that "focus on user X" works when grading.

Part of #5937.

[robertknight]

This code currently reparses the page numbers for every annotation that is matched. That's OK since the number of annotations is expected to be small in the grand scheme of things (hundreds at most). If this needs to be optimized then we can convert annotation page ranges to some pre-parsed representation.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (07b6fcc) 99.44% compared to head (d6c3fc3) 99.44%.

Additional details and impacted files

@@                      Coverage Diff                       @@
##           display-page-numbers-on-cards    #5997   +/-   ##
==============================================================
  Coverage                          99.44%   99.44%           
==============================================================
  Files                                259      260    +1     
  Lines                               9918     9941   +23     
  Branches                            2375     2386   +11     
==============================================================
+ Hits                                9863     9886   +23     
  Misses                                55       55           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[acelaya]

LGTM. I just added a suggestion to reduce conditional nesting in one function.

[acelaya]

Perhaps we can simplify the conditions that need to be mentally dragged by adding an early return for the simplest condition, and adding the rest afterwards:

Suggested change

	if (range.includes('-')) {
	let [start, end] = range.split('-');
	if (!start) {
	start = label;
	}
	if (!end) {
	end = label;
	}
	const [startInt, endInt, labelInt] = [
	parseInt(start),
	parseInt(end),
	parseInt(label),
	];
	if (
	Number.isInteger(startInt) &&
	Number.isInteger(endInt) &&
	Number.isInteger(labelInt)
	) {
	return labelInt >= startInt && labelInt <= endInt;
	} else {
	return false;
	}
	} else {
	return label === range;
	}
	if (!range.includes('-')) {
	return label === range;
	}
	let [start, end] = range.split('-');
	if (!start) {
	start = label;
	}
	if (!end) {
	end = label;
	}
	const [startInt, endInt, labelInt] = [
	parseInt(start),
	parseInt(end),
	parseInt(label),
	];
	if (
	Number.isInteger(startInt) &&
	Number.isInteger(endInt) &&
	Number.isInteger(labelInt)
	) {
	return labelInt >= startInt && labelInt <= endInt;
	}
	return false;

[robertknight]

I agree. I prefer the early-return version as long as that code path is very simple.