Match an LDIF re-import on the entry's dn

Reported again by the submitter's colleague at LINET after #223 was
closed: duplicate checking was implemented for vCard and never for LDIF,
so re-importing an address book still leaves a second copy of everything.
That was deliberate at the time -- the matching key was an open question
I did not want to answer alone -- but the answer had already been given
on #174 and I closed the issue without acting on it.

The answer, in the submitter's words: an attribute that *can* change is
fine, because it will not have changed between two imports minutes apart.
An import is not a sync. That makes the `dn` usable -- it is the only
identity the file carries, and Mozilla's schema defines no UID -- and it
needs no guessing at all, unlike the name-plus-email fallback I had been
weighing.

So `uidFromDn` derives a namespaced, stable uid from the distinguished
name, normalised for the case and spacing two exports of one directory
differ in. A card the book already holds under that uid is updated rather
than duplicated, merged the way the vCard import merges: what the file
carries wins, what it does not mention is left alone. Reported as created
and updated, which is the pair that was asked for.

Three things worth knowing:

Matching is per address book, so two customer directories that each hold
a `cn=John Smith` stay two people as long as they are filed separately.
Imported into one book they would merge, which is the one way this can be
wrong and the reason the escape hatch is worth naming.

The look-alike count stays, and now means something narrower: entries
that `dn` matching could not catch -- one whose `dn` moved between
exports, and anything imported before there was a `dn` to match on. Those
are still only counted, never merged.

A file holding two entries under one `dn` is malformed, since a directory
cannot, and now becomes one card instead of two sharing an identity.

FEATURES gains the re-import behaviour for both formats; it documented
neither.

web/src/store/__tests__/ldif-import.test.ts

@@ -86,15 +86,22 @@ describe("importing an LDIF address book", () => {
     expect(first.name).toMatchObject({ full: "Jane Doe" });
   });
 
-  it("gives each contact an identity of its own, not the entry's directory name", async () => {
+  it("gives each contact an identity derived from its entry, and a distinct one", async () => {
     const sets = server();
     await useContacts.getState().importLdif(TWO, "book1");
     const uids = Object.values(sets[0]!.create!).map((c) => c.uid as string);
-    expect(uids.every((u) => typeof u === "string" && u.length > 0)).toBe(true);
     expect(new Set(uids).size).toBe(2);
-    // A distinguished name says where an entry sat in somebody else's
-    // directory, and must not become the contact's identity here.
-    expect(uids.some((u) => u.includes("cn="))).toBe(false);
+    // Namespaced, so it is never mistaken for a UID a vCard author meant, and
+    // stable, so importing the same file again recognises these.
+    expect(uids.every((u) => u.startsWith("urn:x-ihasmail:ldif:"))).toBe(true);
+  });
+
+  it("gives an entry with no usable dn an identity of its own", async () => {
+    const sets = server();
+    await useContacts.getState().importLdif("dn:\ncn: Nameless Place\nmail: [email protected]\n", "book1");
+    const uid = Object.values(sets[0]!.create!)[0]!.uid as string;
+    expect(uid).not.toContain("urn:x-ihasmail:ldif:");
+    expect(uid.length).toBeGreaterThan(0);
   });
 
   it("says a file held no contacts rather than reporting none imported", async () => {