SearchIdx: Decrement regen_down even for added messages that are later deleted.

Decrement regen_down when visiting messages that appear in %D that we
know will later be deleted.  This ensures consistent message numbers are
generated no matter which commit number is on top.  Allowing deletes to
propagage separately from the messages they delete without causing
problems.

The v2 trees already do this and when the indexes are deleted and
rebuilt they maintain they commit numbers.

Add a v1 version of the v2reindex test to verify that reindexing is
working properly on v1 as well as v2.

Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>

index: avoid false-positive warning on off-by-one

We subtract one from "jobs" to map to "partitions" to account
for the overview index and git fast-import jobs.

v2writable: unindex deleted messages after incremental fetch

The normal behavior is to prevent the deleted messages from
being indexed in the first place.  However, when fetching
incrementally via git; public-inbox-index needs to account for
deleted files which were created outside of the most recent
fetch/reindexing window.

Reported-by: Eric W. Biederman <ebiederm@xmission.com>

Import: Don't copy nulls from emails into git

Recently I ran git --git-dir=lkml/git/1.git fsck
and it reported:
> warning in commit 299dbd50b6995c6debe2275f0df984ce697fb4cc: nulInCommit: NULL byte inthe commit object body

Which I found quite scary.  Nulls in the wrong place have a bad tendency
to make programs misbehave.

It turns out someone had placed "=?iso-8859-1?q?=00?=" at the end of
their subject line.  Which is the mime encoding for NULL.  Email::Mime
had correctly decoded the header, and then public-inbox had simply
copied the contents of the header into the subject line of the git
commit.

To prevent that from causing problems replace nulls in such subject
lines with spaces.

Signed-off-by: Eric Biederman <ebiederm@xmission.com>

MsgTime.pm: Use strptime to compute the time zone

Recently I had trouble cloning lkml/git/0.git because
git fsck on receive was failing.  The output of git fsck was:
> Checking object directories: 100% (256/256), done.
> warning in commit 59173dc1fe67b113ace4ce83e7f522414b3e0404: badTimezone: invalid author/committer line - bad time zone
> warning in commit ff22aaff22eb4479e49e93f697e385f76db51c55: badTimezone: invalid author/committer line - bad time zone
> warning in commit 609b744909693f5f00aff5ed9928beeeee9ded2e: badTimezone: invalid author/committer line - bad time zone
> warning in commit 084572141db8e0d879428afb278bd338f2dbb053: badTimezone: invalid author/committer line - bad time zone
> warning in commit 789d204de27cd12c6da693d903390a241a1a4bca: badTimezone: invalid author/committer line - bad time zone
> warning in commit 0d9a65948b0c957007ca387cd56b690f9bab9c08: badTimezone: invalid author/committer line - bad time zone
> warning in commit f7468c42b4196ee6323afb373ab9323971c38d69: badTimezone: invalid author/committer line - bad time zone
> warning in commit 85e0cd6dd527cd55ad0440f14384529b83818228: badTimezone: invalid author/committer line - bad time zone
> warning in commit f31e19a2e772c9ed00728ef142af9c550ea5de6a: badTimezone: invalid author/committer line - bad time zone
> warning in commit 56eb7384443ef84e17e29504a304a071b189ae67: badTimezone: invalid author/committer line - bad time zone
> warning in commit e4470030471e6810414b9de5e3b52e16f2245d12: badTimezone: invalid author/committer line - bad time zone
> warning in commit f913b48caa097c3b2cb3f491707944f88d52d89f: badTimezone: invalid author/committer line - bad time zone
> warning in commit 4390f26923d572c6dab6cce8282c7cad5520d785: badTimezone: invalid author/committer line - bad time zone
> warning in commit 0f66db71a06bd7d651a0cd80877d8043b70fda20: badTimezone: invalid author/committer line - bad time zone
> warning in commit d71472c40b36dcdf0396afc9778f6137eea45887: badTimezone: invalid author/committer line - bad time zone
> warning in commit e8d3b19a91a2d86b6a91bd19dc811e851398b519: badTimezone: invalid author/committer line - bad time zone
> warning in commit afd9fc0cc87e56ed7736d633e17d0ef77817b3cc: badTimezone: invalid author/committer line - bad time zone
> warning in commit 811b3217708358cf1b75fba4602a64a426fce0f5: badTimezone: invalid author/committer line - bad time zone
> warning in commit e7a751a597c6f5e4770c61bdee6220d55a37cba9: badTimezone: invalid author/committer line - bad time zone
> warning in commit 3e32ad6192fe093e03e6b9346c3a90b16d9905c0: badTimezone: invalid author/committer line - bad time zone
> warning in commit 5e66b47528e79d3bbb769e137f036a1fa99cccf9: badTimezone: invalid author/committer line - bad time zone
> warning in commit d90d67d94ca47142670dff13fcb81ab7afab07bb: badTimezone: invalid author/committer line - bad time zone
> Checking objects: 100% (1711464/1711464), done.
> Checking connectivity: 1711464, done.

Upon examination with git show --pretty=raw all of the problem commits
had a time zone that was not 4 digits long.  This time zone had been
passed straight from the Date line in the email into the author line
of the commit.

Looking into that I discovered that str2time takes into account the
time zone, and was actually able to process these weird time zones.

So get the normalized time zone with strptime and convert it from
seconds from gmt to hours and minutes from gmt.

Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>

v2: fill alternates with old epochs on init from mirrors

For v2 repositories with multiple epochs, we must not forget
about earlier epochs in clones.  Ensure we update the alternates
file with all known epochs up to the current one.

Reported-by: Eric W. Biederman <ebiederm@xmission.com>
  https://public-inbox.org/meta/871scj2vzi.fsf@xmission.com/

additional tests for bad Message-IDs in URLs

Followup-to: 73cfed86d8a8287a
   ("www: use undecoded paths for Message-ID extraction")

Reported-by: Leah Neukirchen <leah@vuxu.org>
  https://public-inbox.org/meta/8736xsb5s5.fsf@vuxu.org/

www: use undecoded paths for Message-ID extraction

In PSGI, PATH_INFO contains URI-decoded paths which cause
problems when Message-IDs contain ambiguous characters for used
for routing.  Instead, extract the undecoded path from
REQUEST_URI and use that.

Reported-by: Leah Neukirchen <leah@vuxu.org>
  https://public-inbox.org/meta/8736xsb5s5.fsf@vuxu.org/

Tweak over.sqlite3 queries for sqlite < 3.8

The query planner in sqlite3 < 3.8 is not very clever, so when it sees
num mentioned in the query filter, it decides not to use the fast idx_ts
index and goes for the much slower autoindex. CentOS-7 still has
sqlite-3.7, so loading the http landing page of a very large archive
(LKML) was taking over 18 seconds, as oppposed to milliseconds on a
system with sqlite-3.8 and above:

$ time sqlite3 -line over.sqlite3 'SELECT ts,ds,ddd FROM over \
  WHERE num > 0 ORDER BY ts DESC LIMIT 1000;' > /dev/null

real    0m19.610s
user    0m17.805s
sys     0m1.805s

$ sqlite3 -line over.sqlite3 'EXPLAIN QUERY PLAN SELECT ts,ds,ddd \
  FROM over WHERE num > 0 ORDER BY ts DESC LIMIT 1000;'
selectid = 0
order = 0
from = 0
detail = SEARCH TABLE over USING INDEX sqlite_autoindex_over_1 (num>?) (~250000 rows)

However, if we slightly tweak the query per SQlite recommendations [1]
by adding + to the num filter, we force it to use the correct index
and see much faster performance:

$ time sqlite3 -line over.sqlite3 'SELECT ts,ds,ddd FROM over \
  WHERE +num > 0 ORDER BY ts DESC LIMIT 1000;' > /dev/null

 real    0m0.007s
 user    0m0.005s
 sys     0m0.002s

$ sqlite3 -line over.sqlite3 'EXPLAIN QUERY PLAN SELECT ts,ds,ddd \
  FROM over WHERE +num > 0 ORDER BY ts DESC LIMIT 1000;'
selectid = 0
order = 0
from = 0
detail = SCAN TABLE over USING INDEX idx_ts (~1464303 rows)

This appears to be the only place where this is needed in order to avoid
running into this issue.

As far as I can tell, this change has no impact on systems running newer
sqlite3 (>= 3.8).

.. [1] https://sqlite.org/optoverview.html#disqualifying_where_clause_terms_using_unary_

Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>

Contribute SELinux policy for EL7

This adds a SELinux policy suitable for RHEL/CentOS 7. It assumes the
following:

- public-inbox-httpd and public-inbox-nntpd are running via systemd
  on sane ports (119 and 80/8080)
- /var/lib/public-inbox is the location for mainrepos
- /var/run/public-inbox is the location for PERL_INLINE_DIRECTORY
- /var/log/public-inbox is the location for logs
- mail delivery is done via postfix-pipe or public-inbox-watch via
  the provided example systemd service

Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>

Makefile.PL: do not depend on git

Otherwise, things do not work from a tarball distribution.

Reported-by: Leah Neukirchen <leah@vuxu.org>
  https://public-inbox.org/meta/871sdfzy80.fsf@gmail.com/

public-inbox-mda: use <sysexits.h> status codes where applicable

Many MTA understand these and map them to sensible SMTP error messages.

Inability to find an inbox results in "5.1.1 user unknown".
Misformatted messages are rejected with "5.6.0 data format error".
Unsupported inbox versions are reported as "5.3.5 local configuration error".

All of these are interpreted as permanent failures.

INSTALL: mention Socket6

examples: add systemd example for public-inbox-watch

I guess I forgot to include this, but I've been running
public-inbox-watch as a systemd service for nearly two
years, now.

respect umask if core.sharedRepository is not set

This is consistent with git itself and the previous behavior
was a result of misunderstanding of how git interprets this.
And adjust tests slightly to match the new behavior.

Reported-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
<38873789-ab42-65a1-20c9-12c30b171f4f@linuxfoundation.org>

workaround Xapian OFD locks w/o close-on-exec

Xapian v1.2.21..v1.2.24 (inclusive) use OFD locks but failed to
set the close-on-exec flag on those locks.  So we must continue
to work around those old versions by ensuring Xapian file
descriptors aren't held any longer than necessary when in
long-running git processes.

Reported-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>

learn: support for v2 repos

Oops, I mainly rely on public-inbox-watch for spam training
and completely forgot this tool existed :x

index: avoid setting NPROC to undef

This quiets a warning inside Spawn.pm

t/search: quiet warning from Encode.pm

This was probably a typo on my part, and quiets a warning:
  Argument contains empty address at .../Email/MIME/Encode.pm line 70

Tested with Email::MIME 1.946

t/v2mda: setup emergency Maildir for test

We can't expect ~/.public-inbox to exist for tests nor should
we be writing to non-temporary directories during tests.

convert+compact: fix when running without ~/.public-inbox/config

Some users may not have any public-inboxes configured, especially in
tests.

content_id: workaround quote handling change in Email::* modules

I'm not entirely sure where the behavior change lies, but
it seems to be in some of the latest CPAN versions of these
modules.  In any case, this only affects the test setup and
not actual behavior.

cf. https://public-inbox.org/meta/2a2bf0e1-fd1f-f8bf-95bc-dac47906ef43@linuxfoundation.org/

public-inbox 1.1.0-pre1

Pre-release for v2 repository support.  Thanks to
The Linux Foundation for supporting this work!

scripts/import_slrnspool: cleanup progress messages

Stop showing redundant slashes and stop showing progress
for messages which do not exist.

scripts/import_slrnspool: support v2 repos

searchidx: preserve umask when starting/committing transactions

Xapian will replace files upon committing, so non-parallel
V2Writable users need to have umask preserved this way.

thread: sort incoming messages by Date

Improve the display by finding any parent when we see out-of-order
References.  This prevents us from having two roots in the test
case like Mail::Thread does.

thread: prevent hidden threads in /$INBOX/ landing page

In retrospect, the loop prevention done by our indexer is not
always sufficient since it can have an improperly sorted
or incomplete References headers.

This bug was triggered multiple bracketed Message-IDs in an
In-Reply-To: header (not References) where the Message-IDs were
in non-chronological order when somebody tried to reply to
different leafs of a thread with a single message.

So we must check for descendents before blindly trying to
use the last one.

Fixes: c6a8fdf71e2c336f ("thread: last Reference always wins")

msgmap: add limit to response for NNTP

All callers in expect to iterate through results.  This
was causing unfairness when fetching large ranges via XHDR
as rtin does :<

Fixes: b8c41362f2a5c8fc "nntp: simplify the long_response API"

search: avoid repeated mbox results from search

Previous search queries already set sort order on the Enquire
object, altering the ordering of results and was causing
messages to be redundantly downloaded via POST /$INBOX/?q=$QUERY&x=m

So stop caching the Search::Xapian::Enquire object since it
wasn't providing any measurable performance improvement.

searchview: do not blindly append "l" parameter to URL

It's ugly and all of our other parameters are omitted
when values are not the default.

TODO: add EPOLLEXCLUSIVE item

Threads are generally discouraged in Perl5, so I won't be using
a dedicated blocking accept4() thread like I would in other
languages.

view: drop redundant References: display code

We no longer need to parse and dedupe References:
ourselves, PublicInbox::MID::references does it for us.

view: wrap To: and Cc: headers in HTML display

It is common to have large amounts of addresses Cc:-ed in large
mailing lists like LKML.  Make them more readable by wrapping
after addresses.  Unfortunately, line breaks inserted by the
MUA get lost when using the public Email::MIME API.

Subject and body lines remain unwrapped, as it's the author's
fault to have such long lines :P

view: untangle loop when showing message headers

The old loop did not help with code clarity with the various
conditional statements.  It also hid a bug where we forgot to
(optionally) obfuscate email addresses in Subject: lines if
search was enabled.

extmsg: use Xapian only for partial matches

"LIKE" in SQLite (and other SQL implementations I've seen) is
expensive with nearly 3 million messages in the archives.

This caused some partial Message-ID lookups to take over 600ms
on my workstation (~300ms on a faster Xeon).  Cut that to below
under 30ms on average on my workstation by relying exclusively
on Xapian for partial Message-ID lookups as we have in the past.

Unlike in the past when we tried using Xapian to match partial
Message-IDs; we now optimize our indexing of Message-IDs to
break apart "words" in Message-IDs for searching, yielding
(hopefully) "good enough" accuracy for folks who get long URLs
broken across lines when copy+pasting.

We'll also drop the (in retrospect) pointless stripping of
"/[tTf]" suffixes for the partial match, since anybody who
hits that codepath would be hitting an invalid message ID.

Finally, limit wildcard expansion to prevent easy DoS vectors
on short terms.

And blame Pine and alpine for generating Message-IDs with
low-entropy prefixes :P

convert: copy description and git config from v1 repo

I noticed I lost a $GIT_DIR/description in a conversion, so we
should preserve it.  While we're at it, we ought to copy any
config in the old repo to the new one.

We will need to warn about cloneurl since it's unfortunately
not an automatic process to update.  Oh well..

searchidx: remove leftover debugging code

I was using this to trace the path of brian's message.

Fixes: 017fed7bc4d33ac4
("searchidx: regenerate and avoid article number gaps on full index")

searchidx: release lock again during v1 batch callback

Relaxing this lock during a v1 --reindex is important to keep
messages showing up in -watch process in a timely manner.
Looks like I deleted an extra line when doing the following
for v2:

s/xdb->commit_transaction/self->commit_txn_lazy/

Fixes: 35ff6bb106909b1c ("replace Xapian skeleton with SQLite overview DB")

disallow "\t" and "\n" in OVER headers

For Subject/To/Cc/From headers, we squeeze them to a space (' ').

For Message-IDs (including References/In-Reply-To), '\t', '\n', '\r'
are deleted since some MUAs might screw them up:

  https://public-inbox.org/git/656C30A1EFC89F6B2082D9B6@localhost/raw

import: cleanup git cat-file processes when ->done

This should reduce idle cat-file instances

filter/rubylang: do not set altid on spam training

I suppose it's a bug or inconsistency that altid is write-only
and their deletions do not get reflected.  But for now, we
do not set it when training spam so there's no window where
an invalid NNTP article number shows up.

This should solve the problem where there's massive gaps
in messages solved by spam training for ruby groups:

https://public-inbox.org/meta/20180307093754.GA27748@dcvr/

TODO: a few more updates

Mainly, v2 stuff is done

fix tests to run without Xapian installed

We'll be ensuring we can run more of the HTTP and all of the
NNTP interface with only SQLite (and not Xapian) installed
in the future.

ensure SQLite and Xapian files respect core.sharedRepository

We can't have files with permissions inconsistent with what's
in git objects.

Merge remote-tracking branch 'origin/master' into v2

* origin/master:
  nntp: allow and ignore empty commands
  mbox: do not barf on queries which return no results
  nntp: fix NEWNEWS command
  searchview: fix non-numeric comparison
  Allow specification of the number of search results to return
  githttpbackend: avoid infinite loop on generic PSGI servers
  http: fix modification of read-only value
  extmsg: use news.gmane.org for Message-ID lookups
  extmsg: rework partial MID matching to favor current inbox
  Update the installation instructions with Fedora package names
  nntp: do not drain rbuf if there is a command pending
  nntp: improve fairness during XOVER and similar commands
  searchidx: do not modify Xapian DB while iterating
  Don't use LIMIT in UPDATE statements

searchidx: revert default BATCH_BYTES to 1_000_000

This increases indexing time by around 10% but roughly
halves memory usage of an -index process.

We will probably make this tunable in the future for people
with bigger/smaller machines.

nntp: allow and ignore empty commands

Somebody hitting "\n" into telnet shouldn't hold a client up
indefinitely and prevent shutdown.

searchidx: increase term positions for all text terms

We do not want phrase searches to cross between independent
fields (filenames/Message-ID vs bodies)

use %H consistently to disable abbreviations

We generally do not want git to waste time finding abbreviations
and we do not want the possibility of them becoming ambiguous
over time, either.

extmsg: remove expensive git path checks

Searching across different inboxes is expensive without
SQLite (or Xapian) installed, so avoid doing expensive tree
lookups in git.  Since SQLite is required for Xapian
support anyways, we won't need to check Xapian, either.

Sites without SQLite installed will simply 404 if somebody
requests a message which isn't in the current inbox.

searchidx: regenerate and avoid article number gaps on full index

Some messages to git@vger went missing from Msgmap from old bugs
and became inaccessible via NNTP.  Forcing NNTP article numbers
when the overview DB came about made the problem more visible when
reindexing old (v1) repositories as all removed spam messages
took up AUTOINCREMENT numbers again before they were removed.

Having large gaps in NNTP article numbers is not good since it
throws off NNTP clients.  This does NOT prevent NNTP clients from
seeing some messages twice, but is better than having them
miss several messages entirely.

We also avoid depending on --reverse in git-log, as
git requires storing an entire commit list in memory for
--reverse, so it's cheaper to store only deleted blobs in the %D
hash since they do not live long.

import: cat_blob drops leading 'From ' lines like Inbox

In case people were running old buggy versions from 2016...
(and -convert should probably clean those up, eventually)

v2: improve deduplication checks

First off, decode text portions of messages since some archived
mail I got was converted from quoted-printable or base-64 to
8bit by the original recipient.  Attempting to merge them with
my own archives (which had no conversion done) led to
unnecessary duplicates showing up.

Then, normalize CRLF line endings in text portions to LF.

In the headers, we relax the content_id hashing to ignore quotes
and lower-case domain names in To, Cc, and From headers since
some mail processors will alter them.

Finally, I've discovered Email::MIME->new($mime->as_string)
does not always round-trip reliably, so we calculate the
content_id twice on user-supplied messages.

v2: generate better Message-IDs for duplicates

While hunting duplicates, I noticed a leading '-' in some
Message-IDs as a result of RFC4648 encoding.  While '-' seems
allowed by RFC5322 and URL-friendly (RFC4648), they are uncommon
and make using Message-IDs as arguments for command-line tools
more difficult.  So prefix them with a datestamp to at least
give readers some sense of the age.  And shorten the "localhost"
hostname to "z" to save space.

search: preserve References in Xapian smsg for x=t view

I'm not sure how useful this view is, but it exists for now.

v2writable: reduce partititions by one

git fast-import and the main V2Writable process combined takes
about one CPU, so avoid having too many Xapian partitions which
cause unnecessary I/O contention.

compact: do not merge v2 repos by default

--no-renumber does not allow merging, and merging is not ideal
for reindexing, either.

v1: remove articles from overview DB

Otherwise articles show up again...

feed: respect feedmax, again

Gigantic feeds probably make some clients unhappy,
clamp it to what it was in the past.

Fixes: b9534449ecce2c59 ("view: avoid offset during pagination")

msgmap: speed up minmax with separate queries

This significantly improves the performance of the NNTP GROUP
command with 2.7 million messages from over 250ms to 700us.
SQLite is weird about this, but at least there's a way to
optimize it.

store less data in the Xapian document

Since we only query the SQLite over DB for OVER/XOVER; do not
need to waste space storing fields To/Cc/:bytes/:lines or the
XNUM term.  We only use From/Subject/References/Message-ID/:blob
in various places of the PSGI code.

For reindexing, we will take advantage of docid stability
in "xapian-compact --no-renumber" to ensure duplicates do not
show up in search results.  Since the PSGI interface is the
only consumer of Xapian at the moment, it has no need to
search based on NNTP article number.

convert: support converting with altid defined

public-inbox-convert ought to be 100% lossless, now

index: allow specifying --jobs=0 to disable multiprocess

Not everybody needs multiprocess support.

v2writable: reduce barriers

Since we handle the overview info synchronously, we only need
barriers in tests, now.  We will use asynchronous checkpoints
to sync less-important Xapian data.

For data deduplication, this requires us to hoist out the
cat-blob support in ::Import for reading uncommitted data
in git.

over: remove forked subprocess

Since the overview stuff is a synchronization point anyways,
move it into the main V2Writable process and allow us to
drop a bunch of code.  This is another step towards making
Xapian optional for v2.

In other words, the fan-out point is moved and the Xapian
partitions no longer need to synchronize against each other:

Before:
                     /-------->\
                    /---------->\
     v2writable -->+----parts----> over
                    \---------->/
                     \-------->/

After:

                          /---------->
                         /----------->
  v2writable --> over-->+----parts--->
                         \----------->
                          \---------->

Since the overview/threading logic needs to run on the same core
that feeds git-fast-import, it's slower for small repos but is
not noticeable in large imports where I/O wait in the partitions
dominates.

over: avoid excessive SELECT

No need to read what we don't need into the Perl process.
Fix some broken capitalization while we're at it.

psgi: ensure /$INBOX/$MESSAGE_ID/T/ endpoint is chronological

We only need to call get_thread beyond 1000 messages for
fetching entire mboxes.  It's probably too much for the HTML
display otherwise.

ensure Xapian and SQLite are still optional for v1 tests

Xapian is size-intensive and SQLite is not strictly necessary for v1.

www: favor reading more from SQLite, and less from Xapian

Favor simpler internal APIs this time around, this cuts
a fair amount of code out and takes another step towards
removing Xapian as a dependency for v2 repos.

nntp: set Xref across multiple inboxes

Noted by Jonathan Corbet in https://lwn.net/Articles/748184/

altid: fix miscopied field name

Oops :x

search: index and allow searching by date-time

Dscho found this useful for finding matching git commits based
on AuthorDate in git.  Add it to the overview DB format, too;
 so in the future we can support v2 repos without Xapian.

https://public-inbox.org/git/nycvar.QRO.7.76.6.1804041821420.55@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz
https://public-inbox.org/git/alpine.DEB.2.20.1702041206130.3496@virtualbox/

over: use only supported and safe SQLite APIs

Some of this jankiness was from early performance problems
and they turned out to be unnecessary measures.

v2writable: refer to git each repository as "epoch"

This hopefully helps for people who try to understand
this design.

v2writable: allow tracking parallel versions

For upgrades, this will let users keep an old version
running while performing "public-inbox-index" on the
newest version.

v2writable: remove redundant remove from Over DB

The Xapian partitions will trigger the removal anyways.
Test this and fix some description/spelling errors
while we're at it.

compact: better handling of over.sqlite3* files

Lets not scare users when they encounter files that are supposed
to be there.  Then, preserve the journal and pipe.lock, even if
they're supposedly unused due to us holding the inbox-wide lock.

support altid mechanism for v2

There's enough gmane links out there in wild that it makes sense
to maintain support for these mappings.

searchview: minor cleanup

$mset->size is probably more obvious than relying on a tied
array and saves us a line.

mbox: do not sort search results

Sorting large msets is a waste when it comes to mboxes
since MUAs should thread and sort them as the user desires.

This forces us to rework each of the mbox download mechanisms
to be more independent of each other, but might make things
easier to reason about.

search: remove unnecessary OP_AND of query

This was vestigial code from the switch to the overview DB

searchmsg: remove unused `tid' and `path' methods

These internal attributes are not exposed and no longer
used in our APIs.

v2writable: recount partitions after acquiring lock

The partition count can change if public-inbox-compact runs
while public-inbox-watch or public-inbox-index is running.

v2writable: do not modify DBs while iterating for ->remove

Xapian may become unhappy if a DB is modified during iteration:
nntp://news.gmane.org/20180228004400.GU12724@survex.com

v2: support incremental indexing + purge

This is important for people running mirrors via "git fetch",
as they need to be kept up-to-date.  Purging is also now
supported in mirrors.

The short-lived "--regenerate" option is gone and is now
implicitly enabled as a result.  It's still cheap when
article number regeneration is unnecessary, as we track
the range for each git repository.

import: rewrite less history during purge

We do not need to rewrite old commits unaffected by the object_id
purge, only newer commits.  This was a state management bug :x

We will also return the new commit ID of rewritten history to
aid in incremental indexing of mirrors for the next change.

init: s/GIT_DIR/REPO_DIR/ in usage

searchidx: ensure duplicated Message-IDs can be linked together

This allows us to emulate the display of thread-aware MUAs when
multiple messages share the same Message-ID.  This also is a
place where "public-inbox-index --reindex" is useful to fix
existing messages and no schema version bump is necessary.

nntp: simplify the long_response API

We we worked around the default range/termination conditions of
long_response in many cases to reduce calls to SQLite or Xapian.
So continue that trend and become more like the PSGI API
which doesn't force callers to specify an article range or
work inside a loop.

msgmap: replace id_batch with ids_after

id_batch had a an overly complicated interface, replace it
with id_batch which is simpler and takes advantage of
selectcol_arrayref in DBI.  This allows simplification of
callers and the diffstat agrees with me.

mbox: remove remaining OFFSET usage in SQLite

We can use id_batch in the common case to speed up full mbox
retrievals.  Gigantic msets are still a problem, but will
be fixed in future commits.

view: avoid offset during pagination

OFFSET in SQLite gets painful to deal with.  Instead,
rely on timestamps (from Received:) for pagination.
This also sets us up for more precise Date searching
in case we want it.

nntp: make XOVER, XHDR, OVER, HDR and NEWNEWS faster

While SQLite is faster than Xapian for some queries we
use, it sucks at handling OFFSET.  Fortunately, we do
not need offsets when retrieving sorted results and
can bake it into the query.

For inbox.comp.version-control.git (v1 Xapian),
XOVER and XHDR are over 20x faster.

rename+rewrite test using Benchmark module

There'll be more performance-related tests in the future.

t/thread-all.t: modernize test to support modern inboxes

We'll be adding more tests in the same vein as this
to improve NNTP performance.

mbox: do not barf on queries which return no results

Having zero search results means we never get a chance
to populate the Content-Disposition header for mbox
downloads.

nntp: fix NEWNEWS command

I guess nobody uses this command (slrnpull does not), and
the breakage was not noticed until I started writing new
tests for multi-MID handling.

Fixes: 3fc411c772a21d8f ("search: drop pointless range processors for Unix timestamp")

over: speedup get_thread by avoiding JOIN

JOIN operations on SQLite can be disasterously slow.
This reduces per-message pages with the thread overview
at the bottom of those pages from over 800ms to ~60ms.
In comparison, the v1 code took around 70-80ms using
Xapian on my machine.

www: rework query responses to avoid COUNT in SQLite

In many cases, we do not care about the total number of
messages.  It's a rather expensive operation in SQLite
(Xapian only provides an estimate).

For LKML, this brings top-level /$INBOX/ loading time from
~375ms to around 60ms on my system.  Days ago, this operation
was taking 800-900ms(!) for me before introducing the SQLite
overview DB.