[Bro-Dev] Configurable &write_expire interval

[Jan Grashöfer]

> Please create a separate pull request for this one first (you can
> merge it into the intel update branch, that'll be fine).

I have opened a new pull request :)

>> expire_func statement. In case the table is serialized having a cached
>> value set, it would be preferable to use this value, wouldn't it?
> 
> It's a question of semantics: what should happen if the Bro
> unserializing it has redef'ed the constant to a different value? I
> think my intuition would expect to use that modified value after
> unserialization.

My intuition would be that the deserialized table is identical to the
serialized one. However, this is a matter of style and shouldn't be
relevant now...

> Yeah, I was thinking about that too. I'd still be curious if the
> overhead of re-evaluating the constant overhead becomes noticable. If
> you're game, you could try a little benchmark just manipulating a
> table plenty times and measure if that changes execution time much.

... I did a quick measurement of the execution time for re-evaluation of
a constant and couldn't detect any performance impact. So I went for
this solution.

A side note: I suspect that the table syncing did and still does not
work as reliable as one would expect. But according to Johanna this will
become deprecated soon, so I did not touch that code.

Best regards,
Jan