Bug#820790: ldapvi: sorts entries alphabetically which can break specific modifications where the order of the definitions is important

[Ralf Becker]

This bug causes editing of a schema definition to fail.

The error message reads:
```
ldap_modify: Other (e.g., implementation specific) error (80)
        additional info: olcObjectClasses: ObjectClass not found: "idmPerson"
Error at: cn={8}yyy,cn=schema,cn=config
```

The reason for this is the sorting of the values.

## Example

This definition is only correct in exactly this order,
because `idmStudent` builds on `idmPerson`:
```
olcObjectClasses: {3}( 1.3.6.1.4.1.xxxx.1 NAME 'idmPerson'
    SUP top AUXILIARY MUST ( uid $ givenName ) )
...
olcObjectClasses: {11}( 1.3.6.1.4.1.xxxx.2 NAME 'idmStudent'
    SUP idmPerson AUXILIARY MAY ( mtr ) )
```

Sorting turns it into:
```
olcObjectClasses: {11}( 1.3.6.1.4.1.xxxx.2 NAME 'idmStudent'
    SUP idmPerson AUXILIARY MAY ( mtr ) )
...
olcObjectClasses: {3}( 1.3.6.1.4.1.xxxx.1 NAME 'idmPerson'
    SUP top AUXILIARY MUST ( uid $ givenName ) )
```

And that then leads to described error.


## Conclusion:

There seems to be no valid reason why the values are sorted.
Attribute values should be taken in *exactly* the order
in which they are entered in `vi`.


## Patch:

This patch ensures that reordering no longer takes place and
fixes the problem in the case shown above.

```
diff --git a/ldapvi/diff.c b/ldapvi/diff.c
index e2787a3..42de566 100644
--- a/ldapvi/diff.c
+++ b/ldapvi/diff.c
@@ -29,8 +29,8 @@ compare_ptr_arrays(GPtrArray *a, GPtrArray *b,
        int i = 0;
        int j = 0;
 
-       qsort(a->pdata, a->len, sizeof(void *), cmp);
-       qsort(b->pdata, b->len, sizeof(void *), cmp);
+//     qsort(a->pdata, a->len, sizeof(void *), cmp);
+//     qsort(b->pdata, b->len, sizeof(void *), cmp);
 
        while (i < a->len && j < b->len) {
                void *ax = g_ptr_array_index(a, i);

```