NO_CHANGELOG=Update doxygen config
NO_DOC=Update doxygen config
NO_TEST=Update doxygen config

It is counter-intuitive to see options of a component that is disabled
at build time. Especially, when the returned value means that the
component is enabled (while it is not so).

Before this patch (on `-DENABLE_FEEDBACK_DAEMON=OFF` build):

```yaml
tarantool> box.cfg()
tarantool> box.cfg.feedback_enabled
---
- true
...
```

After this patch (on `-DENABLE_FEEDBACK_DAEMON=OFF` build):

```yaml
tarantool> box.cfg()
tarantool> box.cfg.feedback_enabled
---
- null
...
```

NB: The following test cases in cartridge are failed with
`-DENABLE_FEEDBACK_DAEMON=OFF` (as before as well as after the patch):

* integration.feedback.test_feedback
* integration.feedback.test_rocks

Since they verify cartridge's additions for the feedback daemon, it is
expected outcome of disabling the component entirely. Ideally we should
conditionally disable those test cases, but it is out of scope here.

Follows up #3308

NO_DOC=I think it is expected behavior and unlikely it requires any
       change in the documentation
NO_TEST=a test would verify behavior of the particular build type, but
        we have no such configuration in CI, so the test would be pretty
        useless
NO_CHANGELOG=seems too minor to highlight it for users

It is convenient to fast check, whether the option was enabled or
disabled. Especially, when cmake is called indirectly, say, by a package
manager on Gentoo.

Follows up #3308

NO_DOC=quite minor build process change
NO_TEST=has no relation to tarantool behavior
NO_CHANGELOG=see NO_DOC

To avoid potential buffer overflows and to make static analyzers happy.

Fixed CWE-120:
- sprintf: does not check for buffer overflows
- strcpy: does not check for buffer overflows when copying to destination
- strcat: does not check for buffer overflows when concatenating to
  destination

Closes #7534

NO_DOC=refactoring
NO_TEST=refactoring
NO_CHANGELOG=refactoring

strlcat is a function from BSD, which is designed to be safer, more
consistent, and less error prone replacement for strcat and strncat.

NO_DOC=internal
NO_CHANGELOG=internal

Part of #7534

The hash index doesn't create a snapshot clarifier, which is used for
filtering out uncommitted tuples from a snapshot. Fix this. Also fix
a bug in hash_snapshot_iterator_next, where we passed a wrong argument
to tuple_data_range. It hasn't fired, because the clarifier didn't work.

Fixes commit ee8ed065 ("txm: clarify all fetched tuples").
Fixes commit f167c1af ("memtx: decompress tuples in snapshot
iterator").

Closes #7539

NO_DOC=bug fix

Gap tracking does not handle gap writes when the key has the same value as
the gap item: review the whole gap write handling logic, refactor it and
fix handling of corner cases along the way.

Co-authored-by: Alexander Lyapunov <alyapunov@tarantool.org>

Closes #7375

NO_DOC=bugfix

Since `ITER_ALL` is an alias to `ITER_GE` in context of TREE index,
denormalize it during iterator creation.

Needed for #7375

NO_CHANGELOG=refactoring
NO_DOC=refactoring
NO_TEST=refactoring

The problem is described in #7073. It was fixed only for
`tree_iterator_start_raw` next method, but other methods used for reverse
iterators are also subject to this bug: move tuple clarification from the
wrapper of iterator `next` methods to individual iterator methods.

Closes #7432

NO_DOC=bugfix

LuaJIT tests are disabled in the scope of the issue [1].

[1] https://github.com/tarantool/tarantool/issues/4819

NO_DOC=ci
NO_TEST=ci
NO_CHANGELOG=ci

The Rust module (see the issue) needs a getter and a setter for decimal
values on the Lua stack. Let's make them part of the module API.

Part of #7228

@TarantoolBot document
Title: Lua/C functions for decimals in the module API

The following functions are added into the module API:

```c
/**
 * Allocate a new decimal on the Lua stack and return
 * a pointer to it.
 */
API_EXPORT box_decimal_t *
luaT_newdecimal(struct lua_State *L);

/**
 * Allocate a new decimal on the Lua stack with copy of given
 * decimal and return a pointer to it.
 */
API_EXPORT box_decimal_t *
luaT_pushdecimal(struct lua_State *L, const box_decimal_t *dec);

/**
 * Check whether a value on the Lua stack is a decimal.
 *
 * Returns a pointer to the decimal on a successful check,
 * NULL otherwise.
 */
API_EXPORT box_decimal_t *
luaT_isdecimal(struct lua_State *L, int index);
```

This change follows the previous commits regarding decimal, uuid and
datetiem functions. See them for details.

Part of #7228

NO_DOC=refactoring, no user-visible changes
NO_TEST=refactoring, no behavior changes
NO_CHANGELOG=refactoring, no user-visible changes

This change follows the previous commits regarding
`luaT_{new,push}decimal()` and `luaT_{new,push}uuid()`. See them for
details.

Part of #7228

NO_DOC=refactoring, no user-visible changes
NO_TEST=refactoring, no behavior changes
NO_CHANGELOG=refactoring, no user-visible changes

This change follows the previous commit regarding `luaT_newdecimal()`
and `luaT_pushdecimal()`, see explanation and details there.

Also changed the `luaL_` prefix to more appropriate `luaT_`. The `struct
tt_uuid` is our own type, the functions are specific to tarantool. So
`luaT_`.

Part of #7228

NO_DOC=refactoring, no user-visible changes
NO_TEST=refactoring, no behavior changes
NO_CHANGELOG=refactoring, no user-visible changes

`luaT_pushdecimal()` now accepts a decimal argument to copy into the Lua
managed memory.

`luaT_newdecimal()` now doing what `luaT_pushdecimal()` did before: just
allocates a storage for decimal on the Lua stack.

This naming looks much more friendly. It also seems that it follow Lua
API names: `lua_push*()` accepts what to push, `lua_new*()` doesn't.

A couple of notes around the change:

* On the first glance it seems that `luaT_pushdecimal()` is redundant,
  because it can be written using `luaT_newdecimal()` + copying. That's
  truth in contexts, where we know size of the internal `decimal_t`
  structure. A user of the module API don't know it and should pass
  `box_decimal_t *` pointer to `luaT_pushdecimal()` to write the value.
* I use `memcpy()` instead of just `*a = *b` in `luaT_pushdecimal()` to
  copy the padding byte content. Who knows, maybe this not-so-legal way
  to hold extra information may be crucial for some use case or will
  allow us to add one field into the structure.

This is preparatory commit for exposing `luaT_*decimal()` functions into
the module API.

Next commits will change uuid, datetime, interval functions in the same
way.

Part of #7228

NO_DOC=refactoring, no user-visible changes
NO_TEST=will be tested in a next commit, after exposing to the
        module API
NO_CHANGELOG=refactoring, no user-visible changes

This way we can use just luaT_isdecimal() instead of two calls:
luaT_isdecimal() + luaT_checkdecimal() or luaT_isdecimal() +
luaL_checkcdata(). It is convenient and we already follow this way in
luaT_istuple().

The difference from luaT_checkdecimal() is that luaT_isdecimal() does
not raise a Lua exception. In may be undesirable and/or complicated to
handle in some contexts.

This is the preparation for exposing luaT_isdecimal() into the module
API.

Part of #7228

NO_DOC=refactoring, no user-visible changes
NO_TEST=will be tested in a next commit, after exposing to the
        module API
NO_CHANGELOG=refactoring, no user-visible changes

We use the tarantool specific prefix for functions that are working with
tarantool specific types. lua_ or luaL_ prefix may be confusing, because
it is not always clear what is the origin of the function and where to
find its documentation.

This change is the preparation for exposing luaT_pushdecimal() and
luaT_isdecimal() into the module API.

While I'm here, I made several tidy changes:

* Added `static` where appropriate.
* Removed luaT_pushdecimalstr() from the header file, because it is not
  used outside of the compilation unit.

Part of #7228

NO_DOC=refactoring, no user-visible changes
NO_TEST=refactoring, nothing new to test
NO_CHANGELOG=refactoring, no user-visible changes

It's possible to hang an instance by some non-yielding request. The
simplest example is `while true do end`. A more true to life one would
be a `select{}` from a large space, or `pairs` iteration over a space
without yields.

Any such request makes the instance unresponsive - it can serve neither
reads nor writes. At the same time, the instance appears alive to other
cluster members: relay thread used to communicate with others is not
hung and continues to send heartbeats every replication_timeout.

The problem is the most severe with Raft leader elections: followers
believe the leader is fine and do not start elections despite leader
being unable to serve reads or writes.

Closes #7512

NO_DOC=bugfix

Currently, there's no notion of a BPS tree read view per se - one can
create an iterator over a regular tree and then "freeze" it. This works
just fine for snapshotting and joining replicas, but this spartan API
doesn't let us implement user read views, because to do that we need to
do lookups and create iterators over a frozen tree as many times as we
want, not just once.

So this patch introduces a concept of bps_tree_view, which contains a
frozen image of a bps_tree and implements a subset of non-modifying
bps_tree methods:

 - bps_tree_view_size
 - bps_tree_view_find
 - bps_tree_view_first
 - bps_tree_view_last
 - bps_tree_view_lower_bound
 - bps_tree_view_lower_bound_elem
 - bps_tree_view_upper_bound
 - bps_tree_view_upper_bound_elem
 - bps_tree_view_iterator_get_elem
 - bps_tree_view_iterator_prev
 - bps_tree_view_iterator_next
 - bps_tree_view_iterator_is_equal

Note, bps_tree and bps_tree_view share bps_tree_iterator, because
iterator methods (get_elem, next, prev, is_equal) take bps_tree or
bps_tree_view. The bps_tree_iterator now contains only block index and
offset.

We could also implement the rest of non-modifying methods, but didn't do
that, because they are not needed to implement user read views:

 - bps_tree_random
 - bps_tree_approximate_count
 - bps_tree_debug_check
 - bps_tree_print

To create a bps_tree_view from a bps_tree, one is supposed to call
bps_tree_view_create. If a bps_tree_view is no longer needed, it should
be destroyed with bps_tree_view_destroy.

Old methods used for creating frozen iterators were dropped:

 - bps_tree_iterator_freeze
 - bps_tree_iterator_destroy

To avoid code duplication, we factored out the common part of bps_tree
and bps_tree_view into a new structure, named bps_tree_common.
Basically, the new structure contains all bps_tree members except
matras, which is stored in bps_tree. The difference between
bps_tree_view and bps_tree is that the latter stores matras_view
instead of matras. The common part contains pointers to matras and
matras_view, which are used by internal implementation to look up
bps_tree blocks.

All internal methods now take bps_tree_common instead of bps_tree.
For all public methods that are implemented both for bps_tree and
bps_tree_view, we have the common implementation defined in _impl
suffixed private function, which is called by the corresponding public
functions.

To ensure that a modifying method isn't called on bps_tree_common object
corresponding to a bps_tree_view because of a bug in the bps_tree
implementation, we added !matras_is_read_view_created assertion to
bps_tree_touch_block.

Closes #7191

NO_DOC=refactoring
NO_CHANGELOG=refactoring

We have a method for getting the number of elements stored in a BPS
tree. Let's use it instead of accessing BPS tree internals directly
so that we can freely refactor BPS tree internals.

NO_DOC=refactoring
NO_TEST=refactoring
NO_CHANGELOG=refactoring

 - Add bps_tree_delete_value to the comment and declarations.
   (All other public methods are there.)
 - Fix typo in a comment: approxiamte -> approximate.
 - Fix comment to bps_tree_random.
 - Remove repeated word 'count' from comments.

NO_DOC=no change
NO_TEST=no change
NO_CHANGELOG=no change

 - Rename bps_tree_iterator_are_equal to bps_tree_iterator_is_equal for
   consistency with other methods that check two objects for equality
   (for example, tt_uuid_is_equal).

 - Rename bps_tree_iterator_first and bps_tree_iterator_last to
   bps_tree_first and bps_tree_last, because these are methods of
   bps_tree, not bps_tree_iterator. Omitting _iterator is also
   consistent with bps_tree_lower_bound and bps_tree_upper_bound
   methods, which also create bps_tree_iterator objects.

NO_DOC=refactoring
NO_TEST=refactoring
NO_CHANGELOG=refactoring

In case of reverse iterators, due to index limitations, we need to clarify
the successor tuple early: this implies that the successor's story is not
always at the top of the history chain, whilst we need to add the gap item
to the story currently present in index — fix this by reusing the
iterators' check logic to set the current iterator's tuple (which is
considered the successor) to a tuple in index.

CLoses #7409

NO_DOC=bugfix

All the 'base' TREE index iterator `next` methods (including
`tree_iterator_start`) internally set the iterator's current tuple to the
one found in the index satisfying the conditions: setting the iterator's
current tuple to the clarified one is redundant and moreover gives a
performance penalty each iteration because of the iterator check logic.

Needed for #7409

NO_CHANGELOG=refactoring
NO_DOC=refactoring
NO_TEST=refactoring

The `next` method of memtx HASH index 'GT' iterator is initially set to
'GT' and is supposed to be set to 'GE' after first iteration: it is
mistakenly set to the 'base' method instead of the full method which also
does tuple clarification — this allows dirty reads. Move the `next` method
change on first iteration to `WRAP_ITERATOR_METHOD` for clarity and
correctness.

Closes #7477

NO_DOC=bugfix

Currently, there's no notion of a LIGHT hash table read view per se -
one can create an iterator over a regular hash table and then "freeze"
it. This works just fine for snapshotting and joining replicas, but this
spartan API doesn't let us implement user read views, because to do that
we need to do lookups and create iterators over a frozen hash table as
many times as we want, not just once.

So this patch introduces a concept of LIGHT(view), which contains a
frozen image of a LIGHT(core) and implements a subset of non-modifying
LIGHT(core) methods:

 - LIGHT(view_count)
 - LIGHT(view_find)
 - LIGHT(view_find_key)
 - LIGHT(view_get)
 - LIGHT(view_iterator_begin)
 - LIGHT(view_iterator_key)
 - LIGHT(view_iterator_get_and_next)

Note, LIGHT(core) and LIGHT(view) share LIGHT(iterator), because
iterator methods (begin, key, get_and_next) take LIGHT(core) or
LIGHT(view). The LIGHT(iterator) now contains only a hash table slot.

We could also implement the rest of non-modifying methods, but didn't do
that, because they are not needed to implement user read views:

 - LIGHT(random)
 - LIGHT(selfcheck)

To create a LIGHT(view) from a LIGHT(core), one is supposed to call
LIGHT(view_create). If a LIGHT(view) is no longer needed, it should be
destroyed with LIGHT(view_destroy).

Old methods used for creating frozen iterators were dropped:

 - LIGHT(iterator_freeze)
 - LIGHT(iterator_destroy)

To avoid code duplication, we factored out the common part of
LIGHT(core) and LIGHT(view) into a new structure, named LIGHT(common).
Basically, the new structure contains all LIGHT(core) members except
matras, which is stored in LIGHT(core). The difference between
LIGHT(view) and LIGHT(core) is that the latter stores matras_view
instead of matras. The common part contains pointers to matras and
matras_view, which are used by internal implementation to look up
LIGHT(record).

All internal methods now take LIGHT(common) instead of LIGHT(core).
For all public methods that are implemented both for LIGHT(core) and
LIGHT(view), we have the common implementation defined in _impl suffixed
private function, which is called by the corresponding public functions.

To ensure that a modifying method isn't called on LIGHT(common) object
corresponding to a LIGHT(view) because of a bug in the LIGHT code, we
added !matras_is_read_view_created assertion to LIGHT(touch_record),
LIGHT(prepare_first_insert), and LIGHT(grow).

Closes #7192

NO_DOC=refactoring
NO_CHANGELOG=refactoring

Currently, matras_get and matras_touch are called directly. Since soon
we'll need to pass a matras_view to those methods, let's add convenience
wrappers.

Needed for #7192

NO_DOC=refactoring
NO_TEST=refactoring
NO_CHANGELOG=refactoring

This commit moves the code that gets the index of a random light
record from the memtx hash index implementation to a new light method.
This gives us more freedom of refactoring the light internals without
modifying the code using it.

After this change, LIGHT(pos_valid) isn't needed anymore so it's
inlined in LIGHT(random).

Needed for #7192

NO_DOC=refactoring
NO_TEST=refactoring
NO_CHANGELOG=refactoring

This commit adds a function that retrieves the number of records stored
in a light hash table and makes light users use it instead of accessing
the light count directly. This gives us more freedom of refactoring the
light internals without modifying the code using it.

Needed for #7192

NO_DOC=refactoring
NO_TEST=refactoring
NO_CHANGELOG=refactoring

Update luacheckrc to suppress all warnings from lua vars with `_` prefix.
This allows to declare a function with an expected standardized interface
without unused var warning.
Fix luacheck warnings in src/box/console.lua.

Closes #5032

NO_CHANGELOG=warning fix
NO_DOC=warning fix
NO_TEST=warning fix

prbuf_check, which is called by prbuf_open, proceeds to scanning the
buffer even if it's empty. On debug build, this results in prbuf_open
reporting that the buffer is corrupted, because we trash the buffer in
prbuf_create. On a release build, this may lead to a hang, in case the
buffer is zeroed out. Let's fix this by returning success from
prbuf_check if the buffer is empty. Note, prbuf_iterator_next doesn't
call prbuf_first_record if the buffer is empty, either.

Needed for https://github.com/tarantool/tarantool-ee/issues/187

NO_DOC=bug fix
NO_CHANGELOG=will be added to EE

This list contains several header files, which has no
`/** cond public */` and `/** \endcond public */` instructions.

While I'm on it, drop `/** \endcond public */` from box.cc.

NO_DOC=pure code health patch, no visible changes
NO_TEST=pure code health patch, no visible changes
NO_CHANGELOG=pure code health patch, no visible changes

The GENERATED and HEADER_FILE_ONLY source file properties should be
followed by a boolean value. CMake 3.20+ warns if it is not so, see [1].

It seems, the module.h properties do not actually change anything
visible in our case.

[1]: https://cmake.org/cmake/help/latest/policy/CMP0118.html

NO_DOC=pure code health patch, no visible changes
NO_TEST=pure code health patch, no visible changes
NO_CHANGELOG=pure code health patch, no visible changes

The main decision made in this patch is how large the public
`box_decimal_t` type should be. Let's look on some calculations.

We're interested in the following values.

* How much decimal digits is stored?
* Size of an internal decimal type (`sizeof(decimal_t)`).
* Size of a buffer to store a string representation of any valid
  `decimat_t` value.
* Largest signed integer type fully represented in decimal_t (number of
  bits).
* Largest unsigned integer type fully represented in decimal_t (number
  of bits).

Now `decimal_t` is defined to store 38 decimal digits. It means the
following values:

| digits | sizeof | string | int???_t | uint???_t |
| ------ | ------ | ------ | -------- | --------- |
| 38     | 36     | 52     | 126      | 127       |

In fact, decNumber (the library we currently use under the hood) allows
to vary the 'decimal digits per unit' parameter, which is 3 by default,
so we can choose density of the representation. For example, for given
38 digits the sizeof is 36 by default, but it may vary from 28 to 47
bytes:

| digits | sizeof     | string | int???_t | uint???_t |
| ------ | ---------- | ------ | -------- | --------- |
| 38     | 36 (28-47) | 52     | 126      | 127       |

If we'll want to store `int128_t` and `uint128_t` ranges, we'll need 39
digits:

| digits | sizeof     | string | int???_t | uint???_t |
| ------ | ---------- | ------ | -------- | --------- |
| 39     | 36 (29-48) | 53     | 130      | 129       |

If we'll want to store `int256_t` and `uint256_t` ranges:

| digits | sizeof     | string | int???_t | uint???_t |
| ------ | ---------- | ------ | -------- | --------- |
| 78     | 62 (48-87) | 92     | 260      | 259       |

If we'll want to store `int512_t` and `uint512_t` ranges:

| digits | sizeof       | string | int???_t | uint???_t |
| ------ | ------------ | ------ | -------- | --------- |
| 155    | 114 (84-164) | 169    | 515      | 514       |

The decision here is what we consdider as possible and what as unlikely.
The patch freeze the maximum amount of bytes in `decimal_t` as 64. So
we'll able to store 256 bit integers and will NOT able to store 512 bit
integers in a future (without the ABI breakage at least).

The script, which helps to calculate those tables, is at end of the
commit message.

Next, how else `box_decimal_*()` library is different from the internal
`decimal_*()`?

* Added a structure that may hold any decimal value from any current or
  future tarantool version.
* Added `box_decimal_copy()`.
* Left `strtodec()` out of scope -- we can add it later.
* Left `decimal_str()` out of scope -- it looks dangerous without at
  least a good explanation when data in the static buffer are
  invalidated. There is `box_decimal_to_string()` that writes to an
  explicitly provided buffer.
* Added `box_decimal_mp_*()` for encoding to/decoding from msgpack.
  Unlike `mp_decimal.h` functions, here we always have `box_decimal_t`
  as the first parameter.
* Left `decimal_pack()` out of scope, because a user unlikely wants to
  serialize a decimal value piece-by-piece.
* Exposed `decimal_unpack()` as `box_decimal_mp_decode_data()` to keep a
  consistent terminogoly around msgpack encoding/decoding.
* More detailed API description, grouping by functionality.

The script, which helps to calculate sizes around `decimal_t`:

```lua
-- See notes in decNumber.h.

-- DECOPUN: DECimal Digits Per UNit
local function unit_size(DECOPUN)
    assert(DECOPUN > 0 and DECOPUN < 10)
    if DECOPUN <= 2 then
        return 1
    elseif DECOPUN <= 4 then
        return 2
    end
    return 4
end

function sizeof_decimal_t(digits, DECOPUN)
    -- int32_t digits;
    -- int32_t exponent;
    -- uint8_t bits;
    -- <..padding..>
    -- <..units..>
    local us = unit_size(DECOPUN)
    local padding = us - 1
    local unit_count = math.ceil(digits / DECOPUN)
    return 4 + 4 + 1 + padding + us * unit_count
end

function string_buffer(digits)
    -- -9.{9...}E+999999999# (# is '\0')
    -- ^ ^      ^^^^^^^^^^^^
    return digits + 14
end

function binary_signed(digits)
    local x = 1
    while math.log10(2 ^ (x - 1)) < digits do
        x = x + 1
    end
    return x - 1
end

function binary_unsigned(digits)
    local x = 1
    while math.log10(2 ^ x) < digits do
        x = x + 1
    end
    return x - 1
end

function digits_for_binary_signed(x)
    return math.ceil(math.log10(2 ^ (x - 1)))
end

function digits_for_binary_unsigned(x)
    return math.ceil(math.log10(2 ^ x))
end

function summary(digits)
    print('digits', digits)
    local sizeof_min = math.huge
    local sizeof_max = 0
    local DECOPUN_sizeof_min
    local DECOPUN_sizeof_max
    for DECOPUN = 1, 9 do
        local sizeof = sizeof_decimal_t(digits, DECOPUN)
        print('sizeof', sizeof, 'DECOPUN', DECOPUN)
        if sizeof < sizeof_min then
            sizeof_min = sizeof
            DECOPUN_sizeof_min = DECOPUN
        end
        if sizeof > sizeof_max then
            sizeof_max = sizeof
            DECOPUN_sizeof_max = DECOPUN
        end
    end
    print('sizeof min', sizeof_min, 'DECOPUN', DECOPUN_sizeof_min)
    print('sizeof max', sizeof_max, 'DECOPUN', DECOPUN_sizeof_max)
    print('string', string_buffer(digits))
    print('int???_t', binary_signed(digits))
    print('uint???_t', binary_unsigned(digits))
end
```

Part of #7228

@TarantoolBot document
Title: Module API for decimals

See the declarations in `src/box/decimal.h` in tarantool sources.

This is preparatory commit for exposing decimals into the module API.
We'll mark the argument in the public function as const, so it would be
more accurate to have it marked as const in the internal API as well.

Part of #7228

NO_DOC=this is internal API, no user-visible changes
NO_TEST=no behavior changes
NO_CHANGELOG=no user-visible changes

It is preparatory commit to add box/decimal.h header, which will hold
module API for decimals.

Part of #7228

NO_DOC=no user-visible changes
NO_TEST=no behavior changes
NO_CHANGELOG=no user-visible changes

This patch fixes the following issue: the submodule_update.yml workflow
always updated the tarantool submodule in the tarantool-ee repo to the
last commit from the `master` branch, even if it was tarantool-ee 2.10.
Now it is fixed.

NO_DOC=ci
NO_TEST=ci
NO_CHANGELOG=ci

* Call error function on rethrow after trace exit.
* Fix handling of errors during snapshot restore.

Part of #7230

NO_DOC=LuaJIT submodule bump
NO_TEST=LuaJIT submodule bump

Commit ed16c1e5 ("build: fix bundled
libcurl and c-ares build on OS X") fixed building libcurl with ares by
adding a dependency on libresolv for Mac OS X. It was forgotten to add
libresolv to check-dependencies exceptions for static build. Do this now.

NO_DOC=CI stuff
NO_TEST=CI stuff
NO_CHANGELOG=CI stuff

Integrate Matthew Haggerty's patches silencing a bunch of gcc build
warnings.

NO_DOC=build
NO_TEST=build
NO_CHANGELOG=build