We have to update the test every time we add a new system tuple format
because it checks the number of spaces that can be created before the
tuple format count limit is reached. Let's loosen the space count check
to avoid that.

We do this for the new memcs engine, which will be introduced to
Tarantool Enterprise Edition, because it will create a tuple format to
serve internal needs.

Needed for tarantool/tarantool-ee#617

NO_DOC=test fix
NO_CHANGELOG=test fix

We need it for the memcs engine. The generic implementation used by
other engines just trashes the iterator object.

Needed for tarantool/tarantool-ee#617

NO_DOC=internal
NO_TEST=internal
NO_CHANGELOG=internal

The stub will be implemented in Tarantool Enterprise Edition.

Needed for tarantool/tarantool-ee#617

NO_DOC=stub
NO_TEST=stub
NO_CHANGELOG=stub

The implementation of the checkpoint and join memtx engine methods
is actually generic: all they need is a read view. Let's allow
other engines that support creation of a consistent read view to be
checkpointed and joined by the memtx engine by setting the corresponding
engine flags.

Currently, there's no such engines, i.e. the only engine setting the new
flags is memtx itself. We will use this feature for new engines.

Needed for tarantool/tarantool-ee#617

NO_DOC=internal
NO_TEST=internal
NO_CHANGELOG=internal

This implies finishing replication TX fibers and stopping applier
threads. This is easy to do using existing applier_stop.

We also need to make sure that there is no client fibers are in
replication code after shutdown. Otherwise we may have difficulties
(assertions) while freeing replication resources. This goal have two
sides. First we have to finish client fibers waiting in replication code
and second we should not allow to wait after shutdonw is done.

Here we probably can achieve first side by just stopping appliers. But in
this case client will get error other than FiberIsCancelled which is
nice to have. So approach is to track client fibers in replication code
and cancel them on shutdown. This approach is also aligned with
iproto/relay shutdown.

There is issue with graceful replication shutdown though. A good example
(on which `replication/shutdown_test.lua` is based) is bootstrapping
a replica with wrong auth in replication URI. In this case applier is
sleeping in reconnect delay and bootstrap code waiting for READY state.
Now comes server shutdown.

Applier is stopped during shutdown and we hit assertion [1]. The issue
is we miss bootstrap fiber notification that applier fiber is cancelled.
That's why the change with `fiber_testcancel` in `applier_f`.

We also drop the assertion in the `replica_on_applier_sync` because
applier can switch to OFF state from any previous state if we cancel
applier fiber.

Part of #8423

[1] Issue assertion stack:
```
  #5  0x00007fe877a54d26 in __assert_fail (
    assertion=0x5637b683b07c "fiber() == applier->fiber",
    file=0x5637b683a03e "./src/box/applier.cc", line=2809,
    function=0x5637b683b05f "void applier_pause(applier*)") at assert.c:101
  #6  0x00005637b62f0f20 in applier_pause (applier=0x5637b7a87a60)
    at /home/shiny/dev/tarantool/src/box/applier.cc:2809
  #7  0x00005637b62f104b in applier_on_state_f (trigger=0x7fe877380a60,
    event=0x5637b7a87a60) at /home/shiny/dev/tarantool/src/box/applier.cc:2845
  #8  0x00005637b645d2e3 in trigger_run_list (list=0x7fe877280de0,
    event=0x5637b7a87a60) at /home/shiny/dev/tarantool/src/lib/core/trigger.cc:100
  #9  0x00005637b645d401 in trigger_run (list=0x5637b7a88098, event=0x5637b7a87a60)
    at /home/shiny/dev/tarantool/src/lib/core/trigger.cc:133
  #10 0x00005637b62e4d6b in trigger_run_xc (list=0x5637b7a88098, event=0x5637b7a87a60)
    at /home/shiny/dev/tarantool/src/lib/core/trigger.h:173
  #11 0x00005637b62e703a in applier_set_state (applier=0x5637b7a87a60,
    state=APPLIER_OFF) at /home/shiny/dev/tarantool/src/box/applier.cc:83
  #12 0x00005637b62f0ab3 in applier_stop (applier=0x5637b7a87a60)
    at /home/shiny/dev/tarantool/src/box/applier.cc:2749
  #13 0x00005637b62dc189 in replication_shutdown ()
```

NO_CHANGELOG=internal
NO_DOC=internal

Currently last applier error is keeped in fiber diag. This leads to some
hacks like the return of -1 from applier fiber to keep the diag (fiber
diag is cleared if fiber return value is 0). Also we do not use applier
fiber diag as it intended - as diag set to current fiber on applier fiber
join. Let's instead keep applier diag in a different place.

Also let's copy error in `applier_wait_for_state` so that fiber error is
not disappeared in case of bootstrap.

Part of #8423

NO_TEST=refactoring
NO_CHANGELOG=refactoring
NO_DOC=refactoring

An iterator doesn't pin the index it was created for. Instead, it holds
a 'weak' reference to it, which is invalidated if the index is dropped.
This is achieved by checking if the index can be found in the space
cache by id every time the reference is accessed. Let's factor out this
weak reference concept into a separate class so that we can reuse it
because we'll also need it to implement the index scanner API.

Needed for #9568

NO_DOC=refactoring
NO_TEST=refactoring
NO_CHANGELOG=refactoring

- Drop testing for macOS 12 since macOS 14 is available
- Add testing for macOS 14

NO_DOC=ci
NO_TEST=ci
NO_CHANGELOG=ci

The issue [1] is closed, and it looks like the problem doesn't exist
now. So removing the respective workaround from the action.

Also, removing the workaround with upgrading packages as it is not
needed anymore because now `brew` just gives a warning instead of
failing when the package is already installed.

[1] https://github.com/gevent/gevent/issues/1721

NO_DOC=ci
NO_TEST=ci
NO_CHANGELOG=ci

From time to time, the step to upload job artifacts to S3 fails due to
the following error:

    Error: Unable to retrieve job ID by provided job name

It happens in the `s3-upload-artifact` action that tries to get job ID
by the name via the `get-job-id` action. Job ID is needed to compose the
proper artifact name. `get-job-id` performs a request to GitHub for the
list of workflow jobs and finds the job by its name and then gets its
ID.

For some reason, sometimes GitHub doesn't give the complete job list and
there is no chance to find the job and get its ID. At least, it has been
noticed for the osx.yml workflow with 36 parallel jobs.

It looks like the issue resides on the GitHub side and the simplest way
to resolve this is to ignore the failure and not fail the whole workflow
due to this GitHub bug.

NO_DOC=ci
NO_TEST=ci
NO_CHANGELOG=ci

When the `freebsd` workflow has become a matrix one in 0bd15468
("ci: mv freebsd testing from per-commit to nightly"), we forgot
to do the corresponding changes in the `Upload artifacts to S3` step.
So adding missing changes.

NO_DOC=ci
NO_TEST=ci
NO_CHANGELOG=ci

When `${{ matrix.tarantool-branch}}` is `release/3.0` or similar, the
step to save build artifacts will fail with the following error:

    Error: Artifact name is not valid: osx-13-x86_64-release/3.0-debug.
    Contains the following character:  Forward slash /

This commit fixes the issue.

NO_DOC=ci
NO_TEST=ci
NO_CHANGELOG=ci

<box/net.box_reconnect_after_gh-3164.test.lua> and
<vinyl/tx_gap_lock.test.lua> checking some objects that should be
collected may fail because these objects are referenced as the upvalues
for a function inlined on some JIT trace. The objects aren't leaked;
tests don't consider the JIT semantics. See more details in [1].

This patch disables JIT for the first test.

The second test itself isn't affected since the commit
tarantool/test-run@33fbace8307e64e66b0b2178ac952b2697673917 ("Add
default server restart to each test run"). Because of this commit, the
`tx.gap_locks` can't be affected by the use of the `create_iterator()`
function in other tests.
But to avoid similar situations in the future, the JIT is disabled for
the `res.next()` function in test utils.

[1]: https://github.com/tarantool/tarantool/wiki/LuaJIT-function-inlining

Closes tarantool/tarantool-qa#233
Closes tarantool/tarantool-qa#276

NO_DOC=fix flaky test
NO_CHANGELOG=see NO_DOC

This patch removes the static_assert(). This static_assert was necessary
because after commit 037e2e44 ("sql: clean-up affinity from SQL
source code") and before commit 078bcf00 ("sql: remove implicit cast
from comparison opcodes"), 4 bits of the p5 field of the struct VdbeOp
were used to store the field type in VDBE comparison opcodes. After the
commit 078bcf00 ("sql: remove implicit cast from comparison
opcodes"), these opcodes no longer need the field type, so this
static_assert() is now unneeded.

NO_DOC=refactoring
NO_TEST=refactoring
NO_CHANGELOG=refactoring

It has been decided to move osx testing to the nightly basis due to lack
of human and hardware resources to support per-commit testing.

Part of tarantool/infra#187

NO_DOC=ci
NO_TEST=ci
NO_CHANGELOG=ci

Currently a leader fails to start with `attempt to index a nil value`
error, when all UUIDs are specified in config. This is caused by the
fact, that we try to apply names to the instance, which have not joined
yet, _cluster record doesn't exist.

We must skip such names. Alert will be dropeed automatically as soon as
the instance is joined.

Closes #9572

NO_DOC=bugfix

Co-authored-by: Alexander Turenko <totktonada.ru@gmail.com>

It has been decided to move freebsd testing to the nightly basis due
to lack of human and hardware resources to support per-commit testing.

Part of tarantool/infra#187

NO_DOC=ci
NO_TEST=ci
NO_CHANGELOG=ci

The approach to build SDK since 3.0 release series is changed and will
be under development for some period of time. So the `test-sdk` job is
just irrelevant now and expected to fail. Let's remove the job until it
is clear how to implement the integration testing in the scope of the
new approach for SDK build.

NO_DOC=ci
NO_TEST=ci
NO_CHANGELOG=ci

Also we now can free all resources allocated in iproto threads.

Part of #8423

NO_TEST=rely on existing tests
NO_CHANGELOG=internal
NO_DOC=internal

When shutdown is started iproto stop accepting new connections yet new
connections are still possible. One can use box.session.new() or use
box.cfg{} to start accepting connections again. This is a minor bug but
in the next patch we are going to free all iproto resources properly and
rely on the fact that we stop accepting new connections. (Before
iproto_free we call iproto_drop_connections to make sure all connections
are finished. But if we continue to accept new connections then
connection that established after dropping may not be finished.)

Part of #8423

NO_CHANGELOG=internal
NO_DOC=internal

To be able to do configuration changes in the iproto_on_shutdown_f in
the next patch.

Part of #8423

NO_TEST=refactoring
NO_CHANGELOG=refactoring
NO_DOC=refactoring

The patch updates curl module to the version 8.5.0 [1][2] that brings a
number of functional fixes and security fix for CVE-2023-46219 (HSTS
long file name clears contents), see description in [2], and updates
CMake module for building curl library.

Changes in CMake module:

- Option `CURL_DISABLE_HEADERS_API` was added and disabled by default [4].
- Option `CURL_DISABLE_BINDLOCAL` was added and disabled by default [5].
- Option `CURL_DISABLE_INSTALL` was added and disabled by default [6].

1. https://curl.se/changes.html#8_5_0
2. https://github.com/curl/curl/compare/curl-8_4_0...curl-8_5_0
3. https://curl.se/docs/CVE-2023-46219.html
4. https://github.com/curl/curl/commit/33493db2af2dc6d9910f5d7c702aae6f63b8a6a6
5. https://github.com/curl/curl/commit/20bb363f25151febe9026b41b8ad65df6db20b68
6. https://github.com/curl/curl/commit/aace27b0965c10394544d1dacc9c2cb2fe0de3d3

NO_DOC=libcurl submodule bump
NO_TEST=libcurl submodule bump

The commit "lib: add ability to disable auths individually" [1][2] in
Curl 8.3.0 removes CURL_DISABLE_CRYPTO_AUTH and introduces CMake options
for a number crypto protocols.

The patch reflects this change in Tarantool's build infrastructure.

1. https://github.com/curl/curl/commit/e92edfbef64448ef461117769881f3ed776dec4e
2. https://github.com/curl/curl/pull/11490

Follows up #9086

NO_CHANGELOG=third_party
NO_DOC=third_party
NO_TEST=third_party

The commit "cmake: improve OpenLDAP builds" [1][2] in Curl deletes CMake
option CURL_USE_OPENLDAP.

The patch reflects this change in Tarantool's build infrastructure.

1. https://github.com/curl/curl/commit/751e168d93b4a58f3fbbe2908c0041ae2f934329
2. https://github.com/curl/curl/pull/12024

Follows up #9086

NO_CHANGELOG=third_party
NO_DOC=third_party
NO_TEST=third_party

Commit 2e31751d ("cmake: introduce target checkpatch") introduced a
target 'checkpatch'. However, target name was incorrect in a dummy
target, that generated when checkpatch tool is not found.
The patch fixes that.

NO_CHANGELOG=cmake
NO_DOC=cmake
NO_TEST=cmake

This reverts commit b471fc97.

Tests for GC finalizers were patched in the luajit
submodule. The submodule was updated in commit 1a0bafd5
("luajit: bump new version").

NO_DOC=Revert CI hack
NO_TEST=Revert CI hack
NO_CHANGELOG=Revert CI hack

Remove all changelogs reported in release notes for 3.0.0.

NO_CHANGELOG=changelog
NO_DOC=changelog
NO_TEST=changelog

New swim:on_member_event triggers use a slightly changed new trigger API
because it uses closures as triggers and a context can be passed.
Firstly, swim:on_member_event returns closure over the new trigger
instead of passed handler. Secondly, ctx can be passed as the second
argument - it is considered as an old trigger if the object is callable
and as ctx otherwise. Also, ctx can be passed as the third argument - it
is considered as name if it is string and as ctx otherwise. And, ctx can
be passed as the fourth argument. When one uses key-value API, ctx can
be passed with key "ctx".

Closes #6484
Closes #8659

NO_DOC=later

Triggers that were moved to the trigger registry accept trigger name as
an optional argument and allow to set triggers using new key-value API.
Let's provide triggers, that were not moved to the trigger registry yet,
with the same functionality. For this purpose the main trigger setter,
lbox_trigger_reset, is updated.

Backward compatibility is a bit broken after this patch. Firstly, all
the triggers were listed in order of their insertion, which is reversed
order of their actual layout and call. Now they are listed in direct
oreder of call.

The patch changes API for all the triggers that were not moved to the
trigger registry except for swim triggers - this case is a bit more
complicated because of context that can be passed to the swim triggers.

Note that argument `top` of `lbox_trigger_reset` is changed to `bottom`
because all passed `top`s became irrelevant with the introduction of the
third argument - changing it to `bottom` will help avoid a similar
problem in the future.

Along the way, make transactional triggers' error more descriptive and
add box.session.on_access_denied to the test - it wasn't tested by
mistake.

Part of #6484
Part of #8659

NO_CHANGELOG=later
NO_DOC=later

The patch rewrites Lua implementation of trigger list in C as a wrapper
over list of lbox triggers.

Backward compatibility is a bit broken after this patch. Firslty, despite
usually all the triggers are inserted to the beginning of the trigger list,
trigger list, implemented in Lua, inserted new triggers at the end. The
patch fixes this inconsistency. Also, triggers using lbox_trigger_reset
return nil when a trigger is deleted, and triggers using Lua implementation
return removed trigger in this case. The behavior is unified now - all
triggers return nil on deletion.

Part of #6484
Part of #8659

NO_CHANGELOG=internal
NO_DOC=internal

Commit 0ea1ba87 ("third_party: update libcurl from 8.3.0 to 8.4.0")
bumps libcurl version and bringed a regression: http client returns
nothing using connection with HTTP/2 protocol. The problem could be
reproduced by etcd-client, see description in issue [1]. The problem in
http client is due to commit "h2: testcase and fix for pausing h2
streams" [2] in libcurl. With reverted commit in libcurl the problem is
gone.

To work around the issue, commit sets HTTP 1.1 as default protocol in
http client.

Needed for #9547

1. https://github.com/tarantool/tarantool/issues/9547
2. https://github.com/curl/curl/commit/6b9a591bf7d82031f463373706d7de1cba0adee6

NO_CHANGELOG=workaround
NO_DOC=workaround
NO_TEST=etcd client's tests in Tarantool EE

Since on_shutdown triggers are fired asynchronously in their own fibers,
they are not referenced by `event_trigger_iterator`. That's why, if
on_shutdown trigger is deleted while it is running (or is scheduled to
run), it will be instantly removed, and when it is finished, segmentation
fault will happen on its finalizer (`func_adapter_end`). Let's reference
all on_shutdown triggers to prevent such situation - they will be deleted
soon along with the whole event subsystem.

Closes #9275

NO_CHANGELOG=bugfix for unreleased feature
NO_DOC=bugfix

The new function allows to reference all triggers from an event to
prevent them from being deleted. Blessed triggers will be freed only
when the whole event subsystem is freed. It will be used for on_shutdown
triggers.

Part of #9275

NO_CHANGELOG=internal
NO_DOC=internal

This patch introduces 3 new transaction-related events, that can be used
for setting user-defined triggers:

 * box.before_commit - triggered when a transaction is ready to commit;
 * box.on_commit - triggered when a transaction is committed;
 * box.on_rollback - triggered when a transaction is rolled back.

Each of them have 3 versions, e.g. `box.on_commit' event has:

 * box.on_commit - global version, called for all transactions;
 * box.on_commit.space.test - called for transactions that write to
   space "test";
 * box.on_commit.space[512] - called for transactions that write to
   space with id 512.

These triggers are implemented via the new trigger registry and work
independently from the core `on_commit' and `on_rollback' triggers.
One of the main advantages of the new triggers is that they can be set
for all transactions, rather than setting them within each transaction.

Space-specific triggers are called prior to global ones. If a trigger-
function fails, the remaining triggers for this event (including global)
are not executed.

If a space-specific trigger is added to the registry within an active
transaction, it may or may not be called on commit/rollback of this
transaction (the behavior is unspecified).

The trigger-function for each event may take an iterator parameter.
Similar to core triggers, the iterator goes through the effects of every
request that changed a space during the transaction.

`box.before_commit' trigger-function restrictions:

 * Yield is allowed (on memtx without mvcc it will abort the txn);
 * Allowed to write into database spaces;
 * If the function raises an error, the transaction is rolled back.

`box.on_commit' and `box.on_rollback' trigger-function restrictions:

 * Yield is forbidden (it will crash Tarantool);
 * The function should not access any database spaces;
 * If the function raises an error, the error is simply logged.

Closes #5717

NO_DOC=later (it depents on the documentation of the `trigger` module)

This patch adds push_iterator() virtual method of the `func_adapter' and
its implementation for Lua functions.

Needed for #5717

NO_DOC=internal
NO_CHANGELOG=internal

A user is unlikely interesting in intermediate changes. Let's just say
that the new declarative configuration is supported now.

NO_DOC=changelog changes
NO_TEST=see NO_DOC

There may be some confusion, so let's start with a background
information.

There are `TT_*` environment variables introduced in commit 1b330121
("box: set box.cfg options via environment variables"). They're
interpreted by the `box.cfg()` call.

There are `TT_*` environment variables introduced in commit 82b0cff9
("config: introduce env source"). They're interpreted by the declarative
configuration logic, when tarantool starts with the `--name <...>` CLI
option.

box.cfg's env variables have names deduced from box.cfg option names,
while config's env variable names are deduced from the config schema.

Some options have the same names here and there, for example
`TT_REPLICATION_ANON` (from `box.cfg.replication_anon` and
`replication.anon`). However, there are ones that have different names,
for example `TT_LISTEN` and `TT_IPROTO_LISTEN`.

Moreover, the declarative configuration has its own restrictions on the
configuration data. For example, `TT_IPROTO_LISTEN` is always a list of
URIs (like `[{"uri": <...>, "params": {<...>}}]`), not a single URI, not
a string, not a number. The declarative configuration has a certain
shape and doesn't allow polymorphic values.

Next, handling of box.cfg's variables by the old code in `load_cfg.lua`
doesn't work well with the declarative configuration flow.

The main reason is that the new configuration flow calls `box.cfg()`
with all the `box.cfg` values set, including default ones. If a user
removes an option from its config, it applies its default. On the same
time it instructs `box.cfg()` to don't read the corresponding
environment variables.

This commit offers a partial solution: it adds support of the most of
the box.cfg environment variables. The values are added into the
configuration data with the lowest priority: if the same value is set
in, for example, a file configuration, the file's value is preferred.

The following box.cfg's environment variables are not handled in this
commit.

* `TT_LOG`
* `TT_METRICS`
* `TT_INSTANCE_NAME`
* `TT_REPLICASET_NAME`
* `TT_CLUSTER_NAME`
* `TT_FORCE_RECOVERY`,
* `TT_READ_ONLY`
* `TT_BOOTSTRAP_LEADER`
* `TT_REPLICATION`
* `TT_REPLICATION_CONNECT_QUORUM`

Fixes #9485

NO_DOC=looks more like a bug fix or a kind of compatibility layer

This function makes it easier to run a code that can't be run directly
for some reason: for example, it needs the initialized database.

It is a wrapper around treegen and justrun.

Part of #9485

NO_DOC=testing helper change
NO_CHANGELOG=see NO_DOC
NO_TEST=see NO_DOC

`TT_LISTEN` and `TT_REPLICATION` environment variables were interpreted
by `box.cfg()` in a confusing way if query parameters with values are
present. For example, `localhost:3301?transport=plain` was interpreted
as the following map: `{['localhost:3301?transport'] = 'plain'}`. Later,
`box.cfg()` looks into this map for known URI fields like `login`,
`password`, `uri`, `host`, `service` and so on. It found nothing and
doesn't start a listening socket.

The reason of such a behaviour is that the environment value is
interpreted as a mapping in the `key=value,key=value` format, because
there is `=` in it.

The patch changes this behavior for an `key=value,key=value` environment
variable that contains `?` in a key: now such a value is not interpreted
as a mapping.

Note: Everything said above is also applicable to the so called
multilisten case: when several URIs are defined in the environment
variable. The following URI list is interpreted correctly now.

NOWRAP
```sh
export TT_LISTEN=localhost:3301?transport=plain,localhost:3302?transport=plain
```
NOWRAP

Note 2: Examples are given with the `plain` transport, which is default,
but the query parameters are the way to define TLS options. They're
supported in Tarantool Enterprise Edition, see [1].

Fixes #9539

NO_DOC=bugfix

[1]: https://www.tarantool.io/en/doc/latest/enterprise/security/#traffic-encryption

`httpc` module has two GC-finalizers: the first one for a Lua http
client (C function `luaT_httpc_cleanup`) and the second one for a Lua
http chunked requests (C function `luaT_httpc_io_cleanup`) introduced in
commit 417c6cb7 ("httpc: introduce stream input/output interface").
In a C implementation HTTP requests depends on structures of HTTP client
and there is a problem with destroying Lua objects in `httpc` module -
these GC-finalizers are not synchronized. This could lead to at least
two problems:

There is a race with GC-finalization that leads to use-after-free errors
when HTTP client is collected before collecting HTTP request. In a
stacktrace the problem looks as below:

```
0x55ca7d47652e in crash_collect+256
0x55ca7d476f6a in crash_signal_cb+100
0x7fb876c42520 in __sigaction+80
0x55ca7d641e51 in curl_slist_free_all+35
0x55ca7d441498 in httpc_request_delete+45
0x55ca7d4653f1 in httpc_io_destroy+27
0x55ca7d4674bc in luaT_httpc_io_cleanup+36
0x55ca7d4e00c7 in lj_BC_FUNCC+70
0x55ca7d4f8364 in gc_call_finalizer+668
0x55ca7d4f8946 in gc_finalize+1387
0x55ca7d4f91e2 in gc_onestep+864
0x55ca7d4f9716 in lj_gc_fullgc+276
...
```

Lua object `http.client` could be GC-collected when chunked HTTP request
is alive. This will lead to an error "IllegalParams: io: request must be
io" because we call a method when Lua object is already a `nil`.

```lua
local url = 'https://bronevichok.ru/'
local c = require('http.client').new()
local r = c:get(url, {chunked = true})
c = nil
collectgarbage()
collectgarbage()
r:read(1) -- IllegalParams: io: request must be io
```

The patch introduces two functions: `httpc_env_finish` and
`curl_env_finish`, that prepares curl and httpc environments for
destruction. HTTP client's GC finalizer now calls `httpc_env_finish`
instead of `httpc_env_destroy`, this prevents from destroying memory
that could be in use by HTTP requests. Additionally `httpc_env_finish`
sets a flag `cleanup`. HTTP environment destroying is called when flag
`cleanup` is set and a there are no active HTTP requests. The main idea
of the patch is a synchronization of destructors for HTTP client and
HTTP chunked requests. Unfortunately, GC will eventually collect HTTP
client object after calling its `__gc`. To prevent this we put a
reference to a Curl's userdata in Lua objects with HTTP chunked requests
and HTTP default client.

Fixes #9346
Fixes #9453

NO_DOC=bugfix