Import an address book in LDIF

Somebody arriving from SOGo, Thunderbird or an LDAP directory has their
contacts in LDIF, and until now the only way in was vCard.

Nothing on the server reads LDIF, so this reads it here, in two pieces
that are two different problems. `ldif.ts` is RFC 2849 and nothing else:
folded lines, base64 values, case-insensitive attribute names, options,
comments, `version:` headers, change records. It knows no attribute by
name. `mozillaAb.ts` knows the attributes and no syntax -- Mozilla's
address book schema, which is what Thunderbird and SOGo write and what the
issue asks for by name. LDIF says nothing about what any attribute means,
so a file is only readable against a schema, and keeping the two apart is
what would let a second schema be added without touching the reader.

Work and home addresses, which the schema keeps in two separate sets of
attributes, come across as two addresses. So do every phone kind, the
second email, the organisation and its units, job title, nickname, web
pages and the AIM handle. The four custom fields have no equivalent in
JSContact and are appended to the note, labelled as Thunderbird labels
them: keeping something somebody chose to write down is worth more than
the tidiness of dropping it.

An entry with neither a name nor an address is skipped rather than
imported as a blank row that is impossible to identify and tedious to find
again to delete. The distinguished name is not used as the contact's uid:
it says where an entry sat in somebody else's directory.

One import control takes either format and decides by what is in the file
rather than by what it is called, because an address book exported as LDIF
arrives as .ldif, .ldi, .txt or with no extension at all.

Closes #174

web/src/views/contacts/ContactsSidebar.tsx

@@ -170,8 +170,8 @@ export function ContactsSidebar() {
       {/* Import and export lived in the pane this replaced. */}
       <div style={{ padding: "12px 8px" }} className="col gap-8">
         <label className="btn btn-sm btn-block">
-          <Upload size={14} />  {t("Import vCard")}
-          <input type="file" accept=".vcf,text/vcard" hidden onChange={(e) => { const f = e.target.files?.[0]; if (f) onImport(f); e.target.value = ""; }} />
+          <Upload size={14} />  {t("Import contacts")}
+          <input type="file" accept=".vcf,.vcard,.ldif,.ldi,text/vcard,text/directory" hidden onChange={(e) => { const f = e.target.files?.[0]; if (f) onImport(f); e.target.value = ""; }} />
         </label>
         <button className="btn btn-sm btn-block" onClick={onExport}><Download size={14} /> {sel.bookId === "all" ? t("Export all") : t("Export book")}</button>
       </div>

web/src/views/contacts/ContactsView.tsx

@@ -96,10 +96,19 @@ export function ContactsView({ id }: { id?: string }) {
       return;
     }
     try {
-      const n = await contacts.importVCard(await f.text(), book.id);
+      const text = await f.text();
+      /*
+       * Which format, decided by what is in the file rather than by what it is
+       * called. A vCard says so on its first line; an address book exported as
+       * LDIF may arrive as .ldif, .ldi, .txt or with no extension at all, and
+       * the name is the least reliable thing about it.
+       */
+      const n = /^\s*BEGIN:VCARD/im.test(text)
+        ? await contacts.importVCard(text, book.id)
+        : await contacts.importLdif(text, book.id);
       toast.success(plural(n, { one: "Imported {n} contact", other: "Imported {n} contacts" }));
     } catch (err) {
-      toast.error((err as Error).message);
+      toast.error(translate("Could not import this file: {error}", { error: (err as Error).message }));
     }
   };