GitLab

Maintainers are listed in the DOAP file, so remove the redundancy (the
reason we needed this file most we because of the autotools build, but
that got removed).

By configuring a `gtkdocentities.in`, gtk-doc stops complaining about a
missing `package_name` and `package_string` entity.

With the drop of the tracker backend, we bumped the API version.
However, this version is apparently also hardcoded in
`folks-generics.vapi`, so this gives build errors.

This commit quickly fixes it by updating the gir_version, but we should
probably just configure it properly through our build system.

Fixes #128

We can drop the dependency on `tracker-devel` now that we've gotten rid
of the tracker backend.

The story of saved contacts in Tracker is a convoluted one,
and this code is mostly an artifact. 65 Million years ago, when
Nokia dominated the world, Maemo/meego relied on Tracker and had
specialized contact apps that used it as a storage.

After Elop hit the Earth, saved contacts barely survived the
event, mostly feeding off a small Evolution plugin. But that
was not meant to last long, the evolution plugin went extinct,
taking all traces of saved contacts with it. Just the ontology
remained, a hollow shell that yes, could be able to hold a
contact, would they still exist.

Modern times arrived, and with them the interest on archeology,
thus this fossilized piece of code is found and taken to the
museum where it belongs.

Should Tracker-using contacts ever exist again, the way to
communicate with them would be radically different, let this code
be a testimony of how it won't be done.

Fixes: #126

We're going to start checking for (accidental) trailing whitespace in
our CI, which is a lot easier if there are no occurrences of that in the
first place.

We're going to start checking for (accidental) use of tabs for
indentation in our CI, which is a lot easier if no tabs are used in the
first place.

When we receive a signal that adds/removes/changes contacts, we get a
list of the affectefd contacts (or their ID's). Since we process them at
a separate point in time in the main loop, we have to make a copy to
make sure that they're still around when being processed.

The current way we do this, is by creating a `Gee.LinkedList`, and
appending each entry at the end (note that appending an item is an O(1)
operation in `Gee.LinkedList` since it keeps track of its last element).
However, there's some problems with this approach:

* Each time an element is added into the list, a little helper object (a
  `Node`) is allocated. This is yet again just another unnecessary
  allocation that we wish to avoid.
* Iterating over any `Gee.Collection` gives you an owned reference to
  each element, meaning we do unnecessary copies or reference count
  fiddling.

Most of these issues can be solved quite elegantly by using
`GLib.GenericArray` (ie. `GPtrArray`), which will keep track of the
owned references, but won't try to do anything fancy with it.

This will always copy the value, even when we don't need it. Use
`get_values()` instead, and return the first element.

By default, getting a property will duplicate the value. However, for
string fields, we can do better, since `E.Contact` then provides a
`get_const()` methods. Especially given the amount of string properties
that are always loaded, this makes a big difference for large address
books.

In a lot of places in Folks, we unnecessarily create a lot of owned
variables. Although the performance impact of a string copy or a
refcount increment is normally completely not a concern, we also do this
in a lot of hot code paths (e.g., for each contact that is loaded). This
in turn mostly impacts larger address books.

Although it's supposedly part of `glib-2.0.vapi`, `string.replace` is
_not_ a function implemented by GLib. Worse, what it does is to create
and compile a `GRegex`, which then gets used to do the substitution.

Since we call `Persona.build_uid()` for each persona, and then even 3
times in a row, we create an amount of unnecessary temporary
allocations that linearly increases with the amount of contacts.

To mitigate this, use a `GString` (aka `GLib.StringBuilder`) and try to
allocate the right amount from the start.

When eds is built with libphonenumber support it also returns "X-EVOLUTION-E164"
parameter on TEL attributes, which breaks the eds:add-persona test, because it
expects exact parameters being returned from eds.

Closes !40

Fixes #121

Done using:
```
codespell \
    --builtin clear,rare,usage \
    --skip './po/*' --skip './.git/*' --skip './NEWS*' \
    --write-changes .
```
and then some manual checking and editing.
Signed-off-by: Philip Withnall <withnall@endlessm.com>

Most of our timeouts are defined by `TestUtils.loop_run_with_timeout()`
anyway, so it shouldn't matter. For slower machines, people can always
use the timeout multiplier used by Meson.

Using `var` in Vala automatically means you take a strong reference,
which in the case of boxed types means that we will copy them (even if
not necessary). We probably want to avoid this inside `Edsf.Persona`,
since that means we might do multiple copies on each contact of a user.

GitLab picks up on this filename to show some extra UI, so let's just
use it instead of HACKING.

It seems that we can sucesfully run the E-D-S backend tests in parallel,
so let's just do that to get them done with quicker.

Fixes #69

After this commit, you can find the latest version of the Folks
documentation on

* https://gnome.pages.gitlab.gnome.org/folks/devhelp/folks/index.htm
* https://gnome.pages.gitlab.gnome.org/folks/gtkdoc/folks/

Fixes #109

We were getting failing CI tests which were almost impossible to debug.
Switching back to latest stable Fedora for now.