Building BIND on newer versions of DragonFly BSD (at least 6.4) fails (w/ and w/o Jemalloc)

While doing some investigations for #3774 (closed), it was found that building BIND 9 is not possible on that platform as our memory management code fails to build on this platform when configuring with both --with-jemalloc=yes and --with-jemalloc=no. I think that it would be fair to make it work at least in the case when jemalloc-specific APIs are not available (like in the case of OpenBSD). BIND builds fine at least for DragonFly 6.2, according to @mnowak report in #3774 (closed). Obviously, that happens due to the changes to OS-specific headers.

When Jemalloc is detected or when building with --with-jemalloc=yes

By default, ./configure tries to detect presence of <malloc_np.h> and assumes that when it is available, Jemalloc specific API is availalbe (mallocx(), sdallocx(), rallocx(), etc). The header usually corresponds to <jemalloc/jemalloc.h> in upstream versions of Jemalloc. In this case HAVE_MALLOC_NP_H is defined in config.h.

That used to be the case for DragonFly BSD, but is not tanymore. On this platform ./configure script works fine, but building BIND will fail as follows:

mem.c: In function 'mem_get':                                                                  
mem.c:343:8: error: implicit declaration of function 'mallocx'; did you mean 'malloc'? [-Werror=implicit-function-declaration]                                                                
  ret = mallocx(size, flags);                                                                  
        ^~~~~~~             
        malloc                  
mem.c:343:6: warning: assignment to 'char *' from 'int' makes pointer from integer without a cast [-Wint-conversion]                                                                          
  ret = mallocx(size, flags);                                                                  
      ^                     
mem.c: In function 'mem_put':          
mem.c:365:2: error: implicit declaration of function 'sdallocx'; did you mean 'reallocf'? [-Werror=implicit-function-declaration]                                                             
  sdallocx(mem, size, flags); 
  ^~~~~~~~              
  reallocf                 
mem.c: In function 'mem_realloc':         
mem.c:375:12: error: implicit declaration of function 'rallocx'; did you mean 'reallocf'? [-Werror=implicit-function-declaration]                                                             
  new_ptr = rallocx(old_ptr, new_size, flags);
            ^~~~~~~                                                                            
            reallocf              
mem.c:375:10: warning: assignment to 'void *' from 'int' makes pointer from integer without a cast [-Wint-conversion]                                                                         
  new_ptr = rallocx(old_ptr, new_size, flags);                                                 
          ^                          
In file included from ./include/isc/hash.h:22,                                                 
                 from mem.c:26:  
mem.c: In function 'mem_initialize':                                                           
mem.c:441:32: error: 'MALLOCX_ZERO' undeclared (first use in this function)                    
  RUNTIME_CHECK(ISC_MEM_ZERO == MALLOCX_ZERO);     
...

Keep in mind that HAVE_MALLOC_NP_H is defined in the case above, as the header is present. The case is that it does not provide the required API.

When building without Jemalloc (--with-jemalloc=yes)

In such a case, jemalloc_shim.h is broken (the file is intended to provide a simple implementation of Jemalloc specific APIs using the available OS-specific capabilities). It fails as follows:

jemalloc_shim.h:44:10: fatal error: malloc.h: No such file or directory
 #include <malloc.h>
          ^~~~~~~~~~

As memory allocator on DragonFly BSD does have malloc_usable_size(), we end up building with HAVE_MALLOC_USABLE_SIZE defined (which is not a surprise, as it is still a custom version of Jemalloc). In such a case, we attempt to include non-standard <malloc.h> ... which is not available on DragonFly BSD anymore. As far as I understand the matter, on newer versions of DragonFly BSD we should use <sys/malloc.h>. Doing so fixes the build. We can solve this by introducing HAVE_SYS_MALLOC_H, I guess.

To lessen maintenance pressure, I would suggest to assume that Jemalloc is not available on Dragon Fly BSD and use the generic code (the one used on OpenBSD)