Re: (ITS#5340) REP_ENTRY_MODIFIABLE bug in dynlist

[h.b.furuseth@usit.uio.no]

I've been trying to do too much at once in this ITS.  My macros
can be simplified to at least use functions for the exposed API.

Since we now have commits related to this (ITS#6423), there's no reason
not to use a common function for the new commits, instead of trying to
get it right each time.

I've committed a variant of this, so far unused:
	slap.h   REP_ENTRY_MUSTFLUSH,
	result.c rs_replace_entry(), rs_ensure_entry_modifiable()
When an overlay can wants to update rs->sr_entry it can use these.

Exception: Some code may want to temporarily replace the entry and
later restore it.  That should be by a push/pop of sr_entry and
(sr_flags & REP_ENTRY_MASK) together.  That is,

push: <save rs->sr_entry and rs->rs_flags>;
      rs->sr_flags &= ~REP_ENTRY_MASK;
      rs->sr_entry  = new entry;
      rs->sr_flags |= new entryflags, if any;

pop:  rs_replace_entry(op, rs, on, <old entry>);
      rs->sr_flags |= (<saved flags> & REP_ENTRY_MASK);

Maybe this is what dynlist.c:dynlist_prepare_entry() wants to do?
I don't see why else it waits to the end of the function to set
rs->sr_flags/sr_entry to the _new_ flags and entry.

Otherwise it should use rs_ensure_entry_modifiable().  Currently
it's still wrong:  Discards the old entry without obeying sr_flags.
I don't know what overlay to pass to entry_modifiable though.

-- 
Hallvard