Improve performance of hfe listpack

[tezc]

This PR contains a few optimizations for hfe listpack.

• Hfe fields are ordered by TTL in the listpack. There are two cases that we want to search listpack according to TTLs:

  • As part of active-expiry, we need to find the fields that are expired. e.g. find fields that have smaller TTLs than given timestamp.
  • When we want to add a new field, we need to find the correct position to maintain the order by TTL. e.g. find the field that has a higher TTL than the one we want to insert.

  Iterating with lpNext() to compare TTLs has a performance cost as lpNext() calls lpValidateIntegrity() for each entry. Instead, this PR adds lpFindCb() to the listpack which accepts a comparator callback. It preserves same validation logic of lpFind() which is faster than search with lpNext().

• We have field name, value, ttl for a single hfe field. Inserting these items one by one to listpack is costly. Especially, as we place fields according to TTL, most additions will end up in the middle of the listpack. Each insert causes realloc + memmove. This PR introduces lpBatchInsert() to add multiple items in one go.

• For hsetf, if we are going to update value and TTL at the same time, currently, we update the value first and later update the TTL (two distinct listpack operation). This PR improves it by doing it with a single update operation.

[tezc]

@sundb I addressed your comments and moved lpBatchInsert() as a separate function. Let's see if we are more comfortable with this one. Maybe we should add a comment that this function might be merged with lpInsert() later in future.

[sundb]

@tezc yeah, it's clear now.
actually, we can use lpDeleteRangeWithEntry instead lpInsert() to do the deletion operation, which is more efficient in the future, then we can remove lpInsert() at that time.

[sundb]

LGTM, but not look closely at the t_hash part.