Stack allocate dict iterators

[bjosv]

Replacing the get & release functions with an initiation function.
Simplifies the code and will make sure we run subscription callbacks in OOM scenarios.

[zuiderkwast]

Nice! Using stack instead of heap is usually a good idea.

I think the same can be done in Redis itself.

[michael-grunder]

This looks good. The only thing to worry about is symbol conflict when hiredis is built as part of Redis, but we aren't exporting dictGetIterator and Redis doesn't have dictInitIterator anyway so we should be good.

000000000000b2b0 l     F .text	0000000000000085              dictFind
000000000000b560 l     F .text	00000000000001a3              dictExpand
000000000000b710 l     F .text	00000000000000ca              _dictClear.isra.0

[michael-grunder]

Merged, thanks!

[zuiderkwast]

Good. Adding dictInitIterator to Redis won't cause any conflict either, will it? It would be equally useful there..

[bjosv]

I thought about if there could be a clash of the two, very different, dict types in redis and hiredis, but came to the conclusion that it seems to work already today.
The pre-processor in a Redis build should pick its own dict.h first, even that hiredis dict.h is in the include path,
and the linkage step have dict.o before libhiredis.a

It exists a compability layer for the two different sds string types, but I guess thats only needed because that type is transferred between two entities, and dict's are only used within each entity?