NEXTID set to 1 in OPENLDAP_REL_ENG_1_2

[Randy Kunkee <kunkee@pluto.ops.NeoSoft.com>]

This would be approximately 1.2.4 version (checked it out about a week
ago).  I recall several email messages awhile ago trying to work out
NEXTID.  I recently loaded an LDIF file using ldif2ldbm -i filename -j 10.
When all was finished, NEXTID contained a '1'.  Did this stuff perhaps
not get merged into this branch?

Also, when reloading an ldif file with IDs in it, I believe the code sets
NEXTID to the last value it sees.  On some architectures (Intel and Alpha
among them) ldbmcat does not dump items in ID number order, and the last
ID written to the ldif file is not necessarily the highest ID.  For example,
an ldif file I dumped yesterday has id 20900, followed by 421, and the
last entry is ID 20735.  Upon reloading, a max function needs to be used.
Here is a suggested patch for ldif2id2entry.c (which only should fix the max
problem, and I haven't tested this yet, except to say that it compiles):

cvs diff ldif2id2entry.c
Index: ldif2id2entry.c
===================================================================
RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/tools/ldif2id2entry.c,v
retrieving revision 1.4.2.10.2.1
diff -r1.4.2.10.2.1 ldif2id2entry.c
15a16
> #define max(a, b)             ( ((a) > (b)) ? (a) : (b) )
37c38
<       ID              id;
---
>       ID              id, maxid;
118c119
<       id = 0;
---
>       id = maxid = 0;
141a143
>                                       maxid = max(id, maxid);
166a169
>                               maxid = max(id, maxid);
188c191
<       id++;
---
>       maxid++;
193c196
<               fprintf( stderr, "Could not write next id %ld\n", id );
---
>               fprintf( stderr, "Could not write next id %ld\n", maxid );
195c198
<               fprintf( fp, "%ld\n", id );
---
>               fprintf( fp, "%ld\n", maxid );