extmsg: don't bother partial matching with <16 chars

It's not worth it, and attempts to wildcard off
single-character Message-IDs(*) causes Xapian to error
out in unpredictable ways:

  something terrible happened at /usr/lib/x86_64-linux-gnu/perl5/5.24/Search/Xapian/Enquire.pm line 54.
    ...propagated at lib/PublicInbox/Search.pm line 209.

So don't bother.

(*) because people blindly hit 'y' or 'n' when git-send-email
    prompted them for In-Reply-To.

t/git.t: do not pass "-b" to git-repack(1)

Allows t/git.t to run on older versions of git without
"-b" and avoids incurring extra I/O traffic for bitmaps.

git: git_unquote handles double-quote and backslash

We need to work with 0x22 (double-quote) and 0x5c (backslash);
even if they're oddball characters in filenames which wouldn't
be used by projects I'd want to work on.

t/git.t: avoid passing read-only value to git_unquote

Older versions of Perl (tested 5.14.2 on Debian wheezy(*),
reported by Konstantin on Perl 5.16.3) considered the result of
concatenating two string literals to be a constant value.

(*) not that other stuff works on wheezy, but t/git.t should.

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

nntp: header responses use CRLF consistently

Alpine is apparently stricter than other clients I've tried
w.r.t. using CRLF for headers.  So do the same thing we do for
bodies to ensure we only emit CRLFs and no bare LFs.

Reported-by: Wang Kang <i@scateu.me>
  https://public-inbox.org/meta/alpine.DEB.2.21.99.1901161043430.29788@la.scateu.me/

config: inbox name checking matches git.git more closely

Actually, it turns out git.git/remote.c::valid_remote_nick
rules alone are insufficient.  More checking is performed as
part of the refname in the git.git/refs.c::check_refname_component

I also considered rejecting URL-unfriendly inbox names entirely,
but realized some users may intentionally configure names not
handled by our WWW endpoint for archives they don't want
accessible over HTTP.

git_unquote: perform modifications in-place

This function doesn't have a lot of callers at the moment so
none of them are affected by this change.  But the plan is to
use this in our WWW code for things, so do it now before we
call it in more places.

Results from a Thinkpad X200 with a Core2Duo P8600 @ 2.4GHz:

Benchmark: timing 10 iterations of cp, ip...
        cp: 12.868 wallclock secs (12.86 usr +  0.00 sys = 12.86 CPU) @  0.78/s (n=10)
        ip: 10.9137 wallclock secs (10.91 usr +  0.00 sys = 10.91 CPU) @  0.92/s (n=10)

Note: I mainly care about unquoted performance because
that's the common case for the target audience of public-inbox.

Script used to get benchmark results against the Linux source tree:
==> bench_unquote.perl <==
use strict;
use warnings;
use Benchmark ':hireswallclock';
my $nr = 50;

my %GIT_ESC = (
a => "\a",
b => "\b",
f => "\f",
n => "\n",
r => "\r",
t => "\t",
v => "\013",
);

sub git_unquote_ip ($) {
return $_[0] unless ($_[0] =~ /\A"(.*)"\z/);
$_[0] = $1;
$_[0] =~ s/\\([abfnrtv])/$GIT_ESC{$1}/g;
$_[0] =~ s/\\([0-7]{1,3})/chr(oct($1))/ge;
$_[0];
}

sub git_unquote_cp ($) {
my ($s) = @_;
return $s unless ($s =~ /\A"(.*)"\z/);
$s = $1;
$s =~ s/\\([abfnrtv])/$GIT_ESC{$1}/g;
$s =~ s/\\([0-7]{1,3})/chr(oct($1))/ge;
$s;
}

chomp(my @files = `git -C ~/linux ls-tree --name-only -r v4.19.13`);
timethese(10, {
cp => sub { for (0..$nr) { git_unquote_cp($_) for @files } },
ip => sub { for (0..$nr) { git_unquote_ip($_) for @files } },
});

searchidx: move git_unquote to PublicInbox::Git

We'll be using it outside of searchidx...

index: allow working on unconfigured inboxes, again

HACKING: update Debian version information

It's been a few years since this was updated...

Merge commit 'mem'

* commit 'mem':
  view: more culling for search threads
  over: cull unneeded fields for get_thread
  searchmsg: remove unused fields for PSGI in Xapian results
  searchview: drop unused {seen} hashref
  searchmsg: remove Xapian::Document field
  searchmsg: get rid of termlist scanning for mid
  httpd: remove psgix.harakiri reference

t/v2writable.t: force more consistent "git log" output

This should probably use lower-level git plumbing, but until
then, consistently add a bunch of --no-* options to "git log"
to get more consistent output.

Noticed-by: Johannes Berg
  https://public-inbox.org/meta/1538164205.14416.76.camel@sipsolutions.net/

check git version requirements

This allows v1 tests to continue working on git 1.8.0 for
now.  This allows git 2.1.4 packaged with Debian 8 ("jessie")
to run old tests, at least.

I suppose it's safe to drop Debian 7 ("wheezy") due to our
dependency on git 1.8.0 for "merge-base --is-ancestor".

Writing V2 repositories requires git 2.6 for "get-mark"
support, so mask out tests for older gits.

INSTALL: Net::Server is not needed for systemd use

Also, move Socket6 down since it's usually pulled in as
a dependency of Net::Server or SpamAssassin; and we can
fail gracefully without it.

daemon: make Socket6 optional, note about Net::Socket::IP

It looks like Net::Socket::IP comes with Perl 5.20 and
later; so we won't have to hassle users with another
package to install.

doc: various overview-level module comments

Hopefully this helps people familiarize themselves with
the source code.

INSTALL: fix Date::Parse dependency for Debian

So yes, both "libdatetime-perl" and "libtimedate-perl" exist
in Debian.  We want the latter for the Date::Parse module.

(And the former pulls in THIRTY-SEVEN dependencies on a fresh
 sid chroot, ohg yrsgcnq vf abg bar bs gurz).

view: more culling for search threads

{mapping} overhead is now down to ~1.3M at the end of
a giant thread from hell.

over: cull unneeded fields for get_thread

On a certain ugly /$INBOX/$MESSAGE_ID/T/ endpoint with 1000
messages in the thread, this cuts memory usage from 2.5M to 1.9M
(which still isn't great, but it's a start).

searchmsg: remove unused fields for PSGI in Xapian results

These fields are only necessary in NNTP and not even stored in
Xapian; so keeping them around for the PSGI web UI search
results wastes nearly 80K when loading large result sets.

searchview: drop unused {seen} hashref

Unused since commit 5f09452bb7e6cf49fb6eb7e6cf166a7c3cdc5433
("view: cull redundant phrases in subjects")

searchmsg: remove Xapian::Document field

We don't need to be carrying this around with the many SearchMsg
objects we have.  This saves about 20K from a large SearchView
"&x=t" response.

searchmsg: get rid of termlist scanning for mid

It doesn't seem to be used anywhere

httpd: remove psgix.harakiri reference

We don't need to set "psgix." extension fields for things
we don't support.  This saves 138 bytes per-client in $env
as measured by Devel::Size::total_size

view: fix wrong date for non-Xapian/SQLite v1 users

We need to parse the MIME object in order to get the
datestamp for those sites.

Fixes: 7d02b9e64455 ("view: stop storing all MIME objects on large threads")

nntp: fix uninitialized variable in event_read

do_write must return 0 or 1.

view: stop storing all MIME objects on large threads

While we try to discard the $smsg (SearchMsg) objects quickly,
they remain referenced via $node (SearchThread::Msg) objects,
which are stored forever in $ctx->{mapping} to cull redundant
words out of subjects in the thread skeleton.

This significantly cuts memory bloat with large search results
with '&x=t'.  Now, the search results overhead of
SearchThread::Msg and linked objects are stable at around 350K
instead of ~7M per response in a rough test (there's more
savings to be had in the same areas).

Several hundred kilobytes is still huge and a large per-client
cost; but it's far better than MEGABYTES per-client.

t/mda_filter_rubylang.t: set PI_EMERGENCY for -mda

Tests should not write to the default ~/.public-inbox/emergency

shrink low-bandwidth pipes under Linux

I've hit /proc/sys/fs/pipe-user-pages-* limits on some systems.
So stop hogging resources on pipes which don't benefit from
giant sizes.

Some of these can use eventfd in the future to further reduce
resource use.

index: quiet down git-log error messages on new inboxes

The new t/*filter_rubylang.t tests call -index immediately
after -init, which causes confusing messages to show up to
the end user.

Check the validity of the ref before calling "git-log".

filter/rubylang: fix SQLite DB lifetime problems

Clearly the AltId stuff was never tested for v2.  Ensure
this tricky filter (which reuses Msgmap to avoid introducing
new serial numbers) doesn't trigger deadlocks SQLite due
to opening a DB for writing multiple times.

I went through several iterations of this change before
going with this one, which is the least intrusive I could
fine.

inboxwritable: drop unused variable

watchmaildir: normalize Maildir pathnames consistently

Remove redundant slashes while we're at it.

watchmaildir: get rid of unused spamdir field

Unused since commit 6c2caa791bd5fbf5c4edb1a4a2c1807e527348a7
("watchmaildir: support v2 repositories")

watchmaildir: support multiple inboxes in the same Maildir

Not sure what I was smoking when I originally wrote this code.

cf. https://public-inbox.org/meta/874li887mp.fsf@vuxu.org/

t/cgi.t: remove more redundant tests

Most of these test cases are in t/plack.t, already; and that
runs much faster.  Just ensure the slashy corner case and search
stuff works.  While we're at it, avoid using the
public-inbox-index command and just use the internal API to
index.

t/cgi.t: move expected failure tests to t/plack.t

No point in implementing these slowly with the CGI wrapper
when PSGI is sufficient for testing.

t/cgi.t: move dumb HTTP git clone/fetch tests to plack.t

No need to test this via CGI .cgi is a wrapper around
PSGI and PSGI tests are way faster.

t/cgi.t: remove atom.xml test

It is redundant with what is in t/plack.t

t/cgi.t: remove redundant redirect check

t/plack.t already has the same test.

t/cgi.t: eliminate some cruft and unnecessary tests

More of this test will be, we use PSGI nowadays; and
most of these tests can be ported over to use PSGI and
not fork+exec as much.

v2writable: disable parallelism on indexlevel=basic

There is no need for parallelism if we're not using Xapian.

config: relax name inbox name restrictions

Since "publicinbox" sections are analogous to git remotes, we
may use the same rules for naming git remotes to reduce
cognitive overhead.

Most notably, this allows '.' in the middle of inbox names,
(e.g. "foo.bar") as it's common for email addresses, too.

use PublicInbox::Config::each_inbox where appropriate

No need to reach into PublicInbox::Config internals and iterate
through the hashref by hand

update and add documentation for repository formats

Remove confusing documentation around ssoma now that we
have NNTP and downloadable mbox support.

Only lightly-checked for grammar and speling, and not yet
formatting.  Edits, corrections and addendums expected :>

t/feed.t: remove ssoma use

No need to waste cycles with this anymore.

t/v2reindex: use the larger text to increase test reliability

libxapian30:amd64 1.4.9-1 on Debian sid seems to give an 8KB
position.glass database with "hello world" as the document
regardless of our indexlevel.  Use the text of the AGPL-3.0 for
a more realisitic Xapian database size.

And perhaps tying our tests to the AGPL will make life more
difficult for would-be copyright violators :>

INSTALL: note Plack and URI::Escape are required at the moment

They really shouldn't be...  Also, it seems like eliminating IPC::Run
is not going to be worth the effort.

inbox: keep Danga::Socket optional

We can't run cleanup stuff without Danga::Socket.

hval: set font-size:100% for all elements

GUI browsers have a tendency to use a larger (though sometimes
smaller) font than the rest of the page for some reason I could
not find...

So set everything to 100% to give uniformity to the page; which
benefits visually-challenged users who want to use gigantic
fonts for the entire page.

TODO: avoid mentioning untrustworthy browser extensions

Old and new versions of Mozilla-based browsers seem to support
userContent.css just fine.

cf. https://www-archive.mozilla.org/unix/customizing.html#usercss
    http://kb.mozillazine.org/index.php?title=UserContent.css

TODO: support integration with cgit/gitweb/etc...

We support searching on blob identifiers for a reason :>

TODO: add a note for exposing a targeted reindexing API

handle "multipart/mixed" messages which are not multipart

I've found two examples on https://lore.kernel.org/lkml/
where the messages declared themselves to be "multipart/mixed"
but were actually plain text:

<87llgalspt.fsf@free.fr>
<200308111450.h7BEoOu20077@mail.osdl.org>

With the mboxrd downloaded, mutt is able to view them without
difficulty.

Note: this change would require reindexing of Xapian to pick up
the changes.  But it's only two ancient messages, the first was
resent by the original sender and the second is too old to be
relevant.

examples/cgit-commit-filter.lua: escape '&' properly in URL

t/git.t: reorder IPC::Run check

We can't skip tests after "use_ok"

t/cgi.t: shorten %ENV setting

No need to write our own loop when an assignment will do.

tests: consolidate process spawning code.

IPC::Run provides a nice simplification in several places; and
we already use it (optionally) on a lot of tests.

For the non-test code, we still rely on our vfork-capable
Inline::C stuff since real-world server processes can get large
enough to where vfork is an advantage.  Maybe Perl5 can use
CLONE_VFORK somehow, one day:

  https://rt.perl.org/Ticket/Display.html?id=128227

Ohg V'q engure cbeg choyvp-vaobk gb Ehol :C

examples/cgit-commit-filter.lua: update URLs

Let's Encrypt is working out nicely, so we can rely on HTTPS,
now.  Use 80x24.org instead of bogomips.org while we're at it,
since I don't think the latter will remain.

TODO: add note for "IMAP IDLE"-like long-polling "git fetch"

wwwstream: always show multi-line cloning instructions

Unfortunately, long inbox names and URLs don't really display well
with my gigantic fonts...

add filter for gmane archives

Extracted from import_slrnspool, since some spools get converted
to mbox or what not.

init: allow --skip of old epochs for -V2 repos

This allows archivists to publish incomplete archives with newer
mail while allowing "0.git" (or "1.git" and so on) epochs to be
added-after-the-fact (without affecting "git clone" followers).

A reindex will be necessary for Xapian and SQLite to catch up
once the old epochs are added; but the reindexing code is also
capable of tolerating missing epochs.

reply: allow ":none=$REASON" in "replyto" config

This can be useful for configuring archives of lists which are
no longer active.

t/git-http-backend.t: remove TEST_CHUNK env setting

TEST_CHUNK hast not been relevant since 2016:
(commit bb38f0fcce73904e "http: chunk in the server, not middleware")

t/perf-nntpd.t: update for RFC 5536 sec 3.2.14 compliance

This performance test doesn't normally get run...

Fixes: dd7049951c052c54 ("Put the NNTP server name into Xref lines")

init: do not set publicinbox.$NAME.indexlevel by default

It is redundant to set default values in the public-inbox
config file.  Lets not clutter up users' screens when they
view or edit the config file.

TODO: add a note for davfs2 Range: support

And maybe I or somebody else interested will implement it, since
fusedav is abandoned upstream and removed from Debian testing:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=840388

Yes, I have fusedav patches at https://bogomips.org/fusedav.git
as noted in the above bug report, but I think davfs2 has more
momentum at the moment.

doc/hosted: add glibc and bug-gnulib mirrors

These have existed for a while, actually, so, we might as well
publicize them.  While we're at it, add a disclaimer to
discourage reliance on single points of failure.

nntp: prevent event_read from firing twice in a row

When a client starts pipelining requests to us which trigger
long responses, we need to keep socket readiness checks disabled
and only enable them when our socket rbuf is drained.

Failure to do this caused aborted clients with
"BUG: nested long response" when Danga::Socket calls event_read
for read-readiness after our "next_tick" sub fires in the
same event loop iteration.

Reported-by: Jonathan Corbet <corbet@lwn.net>
cf. https://public-inbox.org/meta/20181013124658.23b9f9d2@lwn.net/

Add Xrefs to over/xover lines

Putting the Xref field into xover lines allows newsreaders to mark
cross-posted messages read when catching up a group.  That, in turn,
massively improves the life of crazy people who try to follow dozens of
kernel lists, where emails are often heavily cross-posted.

Put the NNTP server name into Xref lines

RFC 5536 sec 3.2.14 says that the server-name in an Xref line is "which
news server generated the header field"; indeed, that is necessary for
newsreaders like gnus to handle references properly.  So pick up the server
name from the config if available (the first name if there's more than
one), from the host name otherwise, and use it rather than the domain
name of the list server.

Tests have been adjusted to match the new behavior.

Import.pm: When purging replace a purged file with a zero length file

This ensures that the number of added files remains the same and thus
the article numbers derived from a repository will remain the same.

I think this is the last place in public-inbox that has to be tweaked to
guarantee the generated article number will remain the same in an public
inbox archive.

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

overidx: preserve `tid' column on re-indexing

Otherwise, walking backwards through history could mean the root
message in a thread forgets its `tid' and it prevents messages
from being looked up by it.

This bug was hidden by the fact that `sid' matches were often
good enough to link threads together.

view: distinguish strict and loose thread matches

The "loose" (Subject:-based) thread matching yields too many
hits for some common subjects (e.g. "[GIT] Networking" on LKML)
and causes thread skeletons to not show the current messages.
Favor strict matches in the query and only add loose matches
if there's space.

While working on this, I noticed the backwards --reindex walk
breaks `tid' on v1 repositories, at least.  That bug was hidden
by the Subject: match logic and not discovered until now.  It
will be fixed separately.

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

Merge branch 'eb/index-incremental'

Incremental indexing fixes from Eric W. Biederman.

These prevents the highest message number in msgmap from
being reassigned after deletes in rare cases and ensures
messages are deleted from msgmap in v2.

* eb/index-incremental:
  V2Writeable.pm: In unindex_oid delete the message from msgmap
  V2Writeable.pm: Ensure that a found message number is in the msgmap
  SearchIdx,V2Writeable: Update num_highwater on optimized deletes
  t/v[12]reindex.t: Verify the num highwater is as expected
  t/v[12]reindex.t Verify num_highwater
  Msgmap.pm: Track the largest value of num ever assigned
  SearchIdx.pm: Always assign numbers backwards during incremental indexing
  t/v[12]reindex.t: Test incremental indexing works
  t/v[12]reindex.t: Test that the resulting msgmap is as expected
  t/v[12]reindex.t: Place expected second in Xapian tests
  t/v2reindex.t: Isolate the test cases more
  t/v1reindex.t: Isolate the test cases
  Import.pm: Don't assume {in} and {out} always exist

V2Writeable.pm: In unindex_oid delete the message from msgmap

Now that we track the num highwater mark it is safe to remove messages
from msgmap that have been previously allocated.  Removing even the
highest numbered article will no longer cause new message numbers to
move backwards.

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

V2Writeable.pm: Ensure that a found message number is in the msgmap

The lookup to see if a num has already been assigned to a message
happens in a temporary copy of message map.  It is possible that the
number has been removed from the current message map.  The
unindex/reindex after a history rewrite triggered by a purge should be
one such case.  Therefore add the number to the msgmap in case it is
not currently present.

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

SearchIdx,V2Writeable: Update num_highwater on optimized deletes

When performing an incremental index update with index_sync if a message is seen
to be both added and deleted update the num_highwater mark even though the
message is not otherwise indexed.

This ensures index_sync generates the same msgmap no matter which commit
it stops at during incremental syncs.

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

t/v[12]reindex.t: Verify the num highwater is as expected

Instrument the tests to verify the highwater num highwater mark is
where it is expected.

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

t/v[12]reindex.t Verify num_highwater

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

Msgmap.pm: Track the largest value of num ever assigned

Today the only thing that prevents public-inbox not reusing the
message numbers of deleted messages is the sqlite autoincrement magic
and that only works part of the time.  The new incremental indexing
test has revealed areas where today public-inbox does try to reuse
numbers of deleted messages.

Reusing the message numbers of existing messages is a problem because
if a client ever sees messages that are subsequently deleted the
client will not see the new messages with their old numbers.

In practice this is difficult to trigger because it requires the most
recently added message to be removed and have the removal show up in a
separate pull request.  Still it can happen and it should be handled.

Instead of infering the highset number ever used by finding the maximum
number in the message map, track the largest number ever assigned directly.

Update Msgmap to track this value and update the indexers to use this
value.

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

search: (really) match the behavior of WWW for indexing text

Not sure what was going through my mind when I made my first
attempt at this, but we really want to make sure we index all
the text we display in the web view (and presumably anything a
reasonable mail client can display).

Followup-to: 0cf6196025d4e4880cd1ed859257ce21dd3cdcf6
    ("search: match the behavior of WWW for indexing text")

SearchIdx.pm: Always assign numbers backwards during incremental indexing

When walking messages newest to oldest, assigning the larger numbers
before smaller numbers ensures older messages get smaller numbers.
This leads to the possibility of a msgmap that can be regenerated when
needed.

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

t/v[12]reindex.t: Test incremental indexing works

Capture interesting commits of the test repository in mark variables.

Use those marks to build interesting scenarios where index_sync proceeds
as if those marks are the heads of the repositor.  Use this capability to
test what happens when adds and deletes are mixed within a repository.

Be sad because things don't yet work as they should.

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

t/v[12]reindex.t: Test that the resulting msgmap is as expected

Deeply inspect the entire message map in the reindexing tests
as the actual message order is significant and can result
in surprises.

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

t/v[12]reindex.t: Place expected second in Xapian tests

Place the expected value second in is and isnt tests because when
these tests fail they report the second value as the expected value.

A report saying got 0 expected 8 'no Xapian search results' can be confusing.

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

t/v2reindex.t: Isolate the test cases more

While inspecting the tests I realized that because we have been
reusing variables there can be a memory between one test case and
another.  Add scopes and local variables to prevent an unintended
memory between one test cases.

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

t/v1reindex.t: Isolate the test cases

While inspecting the tests I realized that because we have been
reusing variables there can be a memory between one test case and
another.  Add scopes and local variables to prevent an unintended
memory between one test and another.

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

Import.pm: Don't assume {in} and {out} always exist

While working on one of the tests I did:
my $im = PublicInbox::V2Writable->new($ibx, 1);
my $im0 = $im->importer();
$im->add($mime);

Which resulted in a warning of the use of an undefined value from
atfork_child, and the test failing nastily.  Inspection of the code
reveals this can happen anytime gfi_start has not been called.

So just fix atfork_child to skip closing file descriptors that have
not yet been setup.

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

ProcessPipe.pm: Use read not sysread

While playing with git fast export I discovered that mixing <> and
read would give inconsistent results.  I tracked the issue down to
using sysread in ProcessPipe instead of plain read.

If it is desirable to use readline I can't see how using sysread
can work as readline to be efficient needs to use buffered I/O.

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

mda: allow configuring globally without spamc support

This reuses some of the configuration from -watch, but remains
independent since some configurations will use -watch for some
inboxes and -mda for others.

The default remains "spamc" for -mda users so nothing changes
without explicit configuration.

Per-inbox configurations may also be supported in the future.

mda: v2: ensure message bodies are indexed

We must not clobber the original message string, as Email::MIME(*)
still needs it for iterating through parts in SearchIdx (but not
when handing it as a raw string to git-fast-import).

I've noticed message bodies (especially dfpre/dpost) were not
getting indexed when going through -mda (no problems with
-watch).  This also did not affect v1 repos, since indexing is a
separate process for v1 and requires re-reading the data from
git.

(*) tested Email::MIME 1.937 on Debian stretch

t/v2mda: make it easy to test v1 repos here, too

It will help track down a bug which only seems to happen in v2 repos.

mda: use InboxWritable

It's a convenient wrapper nowadays, so get rid of some legacy
code and minimize differences from the -watch code.

search: use boolean prefixes for git blob queries

I've hit some case where probabilistic searches don't work when
using dfpre:/dfpost:/dfblob: search prefixes because stemming in
the query parser interferes.

In any case, our indexing code indexes longer/unabbreviated blob
names down to its 7 character abbreviation, so there should be
no need to do wildcard searches on git blob names.

v1: allow upgrading indexlevel=basic to 'medium' or 'full'

For v1 repos, we don't need to write any metadata to Xapian
and changing from 'basic' to 'medium' or 'full' will work.

For v2, the metadata for indexing is stored in msgmap (because
the Xapian databases are partitioned for parallelism), so a
reindex is required.

tests: fixup indexlevel setting in tests

The correct field is underscore-less for consistency with
git-config naming conventions.  While we're at it, beef up
the v2 tests with actual size checks, too.

I also noticed phrase searching still seems to work for
the limited test case, so I left it documented; but the
size checking verifies the space savings.

Import.pm: Deal with potentially missing From and Sender headers

Use ||= '' to ensure that if the From or Sender header is not present
the code sees an empty string and instead of undefined.

I had some email messages with a From field without an @ (because the
sender was local) and without a Sender which were causing errors when
imported.  I think this was bad enough that the email messages were
failing to be imported.

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

searchidx: respect XAPIAN_FLUSH_THRESHOLD env if set

Xapian documents and respect XAPIAN_FLUSH_THRESHOLD to define
the interval in documents to flush, so don't override it with
our own BATCH_BYTES.  This is helpful for initial indexing for
those on slower storage but enough RAM.

It is unnecessary for -watch and frequent incremental indexing;
and it increases transaction times if -watch is playing "catch-up"
if it was stopped for a while.

The original BATCH_BYTES was tuned for a machine with little
memory as the default XAPIAN_FLUSH_THRESHOLD of 10000 documents
was causing swap storms.  Using document counts also proved an
innaccurate estimator of RAM usage compared to the actual bytes
processed.