The issue is we increment `page_count` only on page write. If we fail
for some reason before then page info `min_key` in leaked.

LSAN report for 'vinyl/recovery_quota.test.lua':

```
2024-07-05 13:30:34.605 [478603] main/103/on_shutdown vy_scheduler.c:1668 E> 512/0: failed to compact range (-inf..inf)

=================================================================
==478603==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 4 byte(s) in 1 object(s) allocated from:
    #0 0x5e4ebafcae09 in malloc (/home/shiny/dev/tarantool/build-asan-debug/src/tarantool+0x1244e09) (BuildId: 20c5933d67a3831c4f43f6860379d58d35b81974)
    tarantool#1 0x5e4ebb3f9b69 in vy_key_dup /home/shiny/dev/tarantool/src/box/vy_stmt.c:308:14
    tarantool#2 0x5e4ebb49b615 in vy_page_info_create /home/shiny/dev/tarantool/src/box/vy_run.c:257:23
    tarantool#3 0x5e4ebb48f59f in vy_run_writer_start_page /home/shiny/dev/tarantool/src/box/vy_run.c:2196:6
    tarantool#4 0x5e4ebb48c6b6 in vy_run_writer_append_stmt /home/shiny/dev/tarantool/src/box/vy_run.c:2287:6
    tarantool#5 0x5e4ebb72877f in vy_task_write_run /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1132:8
    tarantool#6 0x5e4ebb73305e in vy_task_compaction_execute /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1485:9
    tarantool#7 0x5e4ebb73e152 in vy_task_f /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1795:6
    tarantool#8 0x5e4ebb01e0b1 in fiber_cxx_invoke(int (*)(__va_list_tag*), __va_list_tag*) /home/shiny/dev/tarantool/src/lib/core/fiber.h:1331:10
    tarantool#9 0x5e4ebc389ee0 in fiber_loop /home/shiny/dev/tarantool/src/lib/core/fiber.c:1182:18
    tarantool#10 0x5e4ebd3e9595 in coro_init /home/shiny/dev/tarantool/third_party/coro/coro.c:108:3

SUMMARY: AddressSanitizer: 4 byte(s) leaked in 1 allocation(s).
```

NO_TEST=covered by existing tests (ASAN build)
NO_DOC=bugfix

The issue is we increment `page_count` only on page write. If we fail
for some reason before then page info `min_key` in leaked.

LSAN report for 'vinyl/recovery_quota.test.lua':

```
2024-07-05 13:30:34.605 [478603] main/103/on_shutdown vy_scheduler.c:1668 E> 512/0: failed to compact range (-inf..inf)

=================================================================
==478603==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 4 byte(s) in 1 object(s) allocated from:
    #0 0x5e4ebafcae09 in malloc (/home/shiny/dev/tarantool/build-asan-debug/src/tarantool+0x1244e09) (BuildId: 20c5933d67a3831c4f43f6860379d58d35b81974)
    tarantool#1 0x5e4ebb3f9b69 in vy_key_dup /home/shiny/dev/tarantool/src/box/vy_stmt.c:308:14
    tarantool#2 0x5e4ebb49b615 in vy_page_info_create /home/shiny/dev/tarantool/src/box/vy_run.c:257:23
    tarantool#3 0x5e4ebb48f59f in vy_run_writer_start_page /home/shiny/dev/tarantool/src/box/vy_run.c:2196:6
    tarantool#4 0x5e4ebb48c6b6 in vy_run_writer_append_stmt /home/shiny/dev/tarantool/src/box/vy_run.c:2287:6
    tarantool#5 0x5e4ebb72877f in vy_task_write_run /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1132:8
    tarantool#6 0x5e4ebb73305e in vy_task_compaction_execute /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1485:9
    tarantool#7 0x5e4ebb73e152 in vy_task_f /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1795:6
    tarantool#8 0x5e4ebb01e0b1 in fiber_cxx_invoke(int (*)(__va_list_tag*), __va_list_tag*) /home/shiny/dev/tarantool/src/lib/core/fiber.h:1331:10
    tarantool#9 0x5e4ebc389ee0 in fiber_loop /home/shiny/dev/tarantool/src/lib/core/fiber.c:1182:18
    tarantool#10 0x5e4ebd3e9595 in coro_init /home/shiny/dev/tarantool/third_party/coro/coro.c:108:3

SUMMARY: AddressSanitizer: 4 byte(s) leaked in 1 allocation(s).
```

NO_TEST=covered by existing tests (ASAN build)
NO_DOC=bugfix

The issue is we increment `page_count` only on page write. If we fail
for some reason before then page info `min_key` in leaked.

LSAN report for 'vinyl/recovery_quota.test.lua':

```
2024-07-05 13:30:34.605 [478603] main/103/on_shutdown vy_scheduler.c:1668 E> 512/0: failed to compact range (-inf..inf)

=================================================================
==478603==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 4 byte(s) in 1 object(s) allocated from:
    #0 0x5e4ebafcae09 in malloc (/home/shiny/dev/tarantool/build-asan-debug/src/tarantool+0x1244e09) (BuildId: 20c5933d67a3831c4f43f6860379d58d35b81974)
    tarantool#1 0x5e4ebb3f9b69 in vy_key_dup /home/shiny/dev/tarantool/src/box/vy_stmt.c:308:14
    tarantool#2 0x5e4ebb49b615 in vy_page_info_create /home/shiny/dev/tarantool/src/box/vy_run.c:257:23
    tarantool#3 0x5e4ebb48f59f in vy_run_writer_start_page /home/shiny/dev/tarantool/src/box/vy_run.c:2196:6
    tarantool#4 0x5e4ebb48c6b6 in vy_run_writer_append_stmt /home/shiny/dev/tarantool/src/box/vy_run.c:2287:6
    tarantool#5 0x5e4ebb72877f in vy_task_write_run /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1132:8
    tarantool#6 0x5e4ebb73305e in vy_task_compaction_execute /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1485:9
    tarantool#7 0x5e4ebb73e152 in vy_task_f /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1795:6
    tarantool#8 0x5e4ebb01e0b1 in fiber_cxx_invoke(int (*)(__va_list_tag*), __va_list_tag*) /home/shiny/dev/tarantool/src/lib/core/fiber.h:1331:10
    tarantool#9 0x5e4ebc389ee0 in fiber_loop /home/shiny/dev/tarantool/src/lib/core/fiber.c:1182:18
    tarantool#10 0x5e4ebd3e9595 in coro_init /home/shiny/dev/tarantool/third_party/coro/coro.c:108:3

SUMMARY: AddressSanitizer: 4 byte(s) leaked in 1 allocation(s).
```

Closes tarantool#10489
Part-of tarantool#10211

NO_TEST=covered by existing tests
NO_DOC=bugfix

The issue is we increment `page_count` only on page write. If we fail
for some reason before then page info `min_key` in leaked.

LSAN report for 'vinyl/recovery_quota.test.lua':

```
2024-07-05 13:30:34.605 [478603] main/103/on_shutdown vy_scheduler.c:1668 E> 512/0: failed to compact range (-inf..inf)

=================================================================
==478603==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 4 byte(s) in 1 object(s) allocated from:
    #0 0x5e4ebafcae09 in malloc (/home/shiny/dev/tarantool/build-asan-debug/src/tarantool+0x1244e09) (BuildId: 20c5933d67a3831c4f43f6860379d58d35b81974)
    tarantool#1 0x5e4ebb3f9b69 in vy_key_dup /home/shiny/dev/tarantool/src/box/vy_stmt.c:308:14
    tarantool#2 0x5e4ebb49b615 in vy_page_info_create /home/shiny/dev/tarantool/src/box/vy_run.c:257:23
    tarantool#3 0x5e4ebb48f59f in vy_run_writer_start_page /home/shiny/dev/tarantool/src/box/vy_run.c:2196:6
    tarantool#4 0x5e4ebb48c6b6 in vy_run_writer_append_stmt /home/shiny/dev/tarantool/src/box/vy_run.c:2287:6
    tarantool#5 0x5e4ebb72877f in vy_task_write_run /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1132:8
    tarantool#6 0x5e4ebb73305e in vy_task_compaction_execute /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1485:9
    tarantool#7 0x5e4ebb73e152 in vy_task_f /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1795:6
    tarantool#8 0x5e4ebb01e0b1 in fiber_cxx_invoke(int (*)(__va_list_tag*), __va_list_tag*) /home/shiny/dev/tarantool/src/lib/core/fiber.h:1331:10
    tarantool#9 0x5e4ebc389ee0 in fiber_loop /home/shiny/dev/tarantool/src/lib/core/fiber.c:1182:18
    tarantool#10 0x5e4ebd3e9595 in coro_init /home/shiny/dev/tarantool/third_party/coro/coro.c:108:3

SUMMARY: AddressSanitizer: 4 byte(s) leaked in 1 allocation(s).
```

Closes tarantool#10489
Part-of tarantool#10211

NO_TEST=covered by existing tests
NO_DOC=bugfix

The issue is we increment `page_count` only on page write. If we fail
for some reason before then page info `min_key` in leaked.

LSAN report for 'vinyl/recovery_quota.test.lua':

```
2024-07-05 13:30:34.605 [478603] main/103/on_shutdown vy_scheduler.c:1668 E> 512/0: failed to compact range (-inf..inf)

=================================================================
==478603==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 4 byte(s) in 1 object(s) allocated from:
    #0 0x5e4ebafcae09 in malloc (/home/shiny/dev/tarantool/build-asan-debug/src/tarantool+0x1244e09) (BuildId: 20c5933d67a3831c4f43f6860379d58d35b81974)
    tarantool#1 0x5e4ebb3f9b69 in vy_key_dup /home/shiny/dev/tarantool/src/box/vy_stmt.c:308:14
    tarantool#2 0x5e4ebb49b615 in vy_page_info_create /home/shiny/dev/tarantool/src/box/vy_run.c:257:23
    tarantool#3 0x5e4ebb48f59f in vy_run_writer_start_page /home/shiny/dev/tarantool/src/box/vy_run.c:2196:6
    tarantool#4 0x5e4ebb48c6b6 in vy_run_writer_append_stmt /home/shiny/dev/tarantool/src/box/vy_run.c:2287:6
    tarantool#5 0x5e4ebb72877f in vy_task_write_run /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1132:8
    tarantool#6 0x5e4ebb73305e in vy_task_compaction_execute /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1485:9
    tarantool#7 0x5e4ebb73e152 in vy_task_f /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1795:6
    tarantool#8 0x5e4ebb01e0b1 in fiber_cxx_invoke(int (*)(__va_list_tag*), __va_list_tag*) /home/shiny/dev/tarantool/src/lib/core/fiber.h:1331:10
    tarantool#9 0x5e4ebc389ee0 in fiber_loop /home/shiny/dev/tarantool/src/lib/core/fiber.c:1182:18
    tarantool#10 0x5e4ebd3e9595 in coro_init /home/shiny/dev/tarantool/third_party/coro/coro.c:108:3

SUMMARY: AddressSanitizer: 4 byte(s) leaked in 1 allocation(s).
```

Closes tarantool#10489
Part-of tarantool#10211

NO_TEST=covered by existing tests
NO_DOC=bugfix

Crash the program after printing the first error report (WARNING: USE AT YOUR OWN RISK!). The flag has effect only if code was compiled with -fsanitize-recover=address compile option.

```
 [061] replication/tarantoolgh-5430-cluster-mvcc.test.lua                     [ pass ]
[050]
[050]
[050] [Instance "box" returns with non-zero exit code: 1]
[050]
[050] [test-run server "box"] Last 15 lines of the log file /tmp/t/050_box/box.log:
[050]     tarantool#9 0x55d6c6868851  (<unknown module>)
[050]
[050] Direct leak of 342 byte(s) in 5 object(s) allocated from:
[050]     #0 0x55d69b184cae in malloc (/__w/tarantool/tarantool/src/tarantool+0x1268cae) (BuildId: 4f3fed4334a726219fb69119e67d451f0cb1ccfa)
[050]     tarantool#1 0x55d69d50040c in small_asan_alloc /__w/tarantool/tarantool/src/lib/small/small/util.c:94:24
[050]     tarantool#2 0x55d69d4fcb3c in smalloc /__w/tarantool/tarantool/src/lib/small/small/small_asan.c:57:5
[050]     tarantool#3 0x55d69ce3782f in runtime_tuple_new /__w/tarantool/tarantool/src/box/tuple.c:138:27
[050]     tarantool#4 0x55d69ce33fac in tuple_new /__w/tarantool/tarantool/src/box/tuple.h:801:9
[050]     tarantool#5 0x55d69ce34844 in box_tuple_new /__w/tarantool/tarantool/src/box/tuple.c:845:22
[050]     tarantool#6 0x55d69b523021 in session_settings_index_get /__w/tarantool/tarantool/src/box/session_settings.c:261:12
[050]     tarantool#7 0x55d69b284077 in index_get(index*, char const*, unsigned int, tuple**) /__w/tarantool/tarantool/src/box/index.h:909:9
[050]     tarantool#8 0x55d69b282794 in box_index_get /__w/tarantool/tarantool/src/box/index.cc:390:11
[050]     tarantool#9 0x55d6c685ea09  (<unknown module>)
[050]
[050] SUMMARY: AddressSanitizer: 5627 byte(s) leaked in 83 allocation(s).
[055] box-luatest/gh_8530_alter_space_snapshot_test.>               [ pass ]
```

1. https://github.com/tarantool/tarantool/actions/runs/10454868034/job/28948757147?pr=10431
2. https://github.com/google/sanitizers/wiki/AddressSanitizerFlags

NO_CHANGELOG=internal
NO_DOC=internal
NO_TEST=internal

The issue is we increment `page_count` only on page write. If we fail
for some reason before then page info `min_key` in leaked.

LSAN report for 'vinyl/recovery_quota.test.lua':

```
2024-07-05 13:30:34.605 [478603] main/103/on_shutdown vy_scheduler.c:1668 E> 512/0: failed to compact range (-inf..inf)

=================================================================
==478603==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 4 byte(s) in 1 object(s) allocated from:
    #0 0x5e4ebafcae09 in malloc (/home/shiny/dev/tarantool/build-asan-debug/src/tarantool+0x1244e09) (BuildId: 20c5933d67a3831c4f43f6860379d58d35b81974)
    tarantool#1 0x5e4ebb3f9b69 in vy_key_dup /home/shiny/dev/tarantool/src/box/vy_stmt.c:308:14
    tarantool#2 0x5e4ebb49b615 in vy_page_info_create /home/shiny/dev/tarantool/src/box/vy_run.c:257:23
    tarantool#3 0x5e4ebb48f59f in vy_run_writer_start_page /home/shiny/dev/tarantool/src/box/vy_run.c:2196:6
    tarantool#4 0x5e4ebb48c6b6 in vy_run_writer_append_stmt /home/shiny/dev/tarantool/src/box/vy_run.c:2287:6
    tarantool#5 0x5e4ebb72877f in vy_task_write_run /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1132:8
    tarantool#6 0x5e4ebb73305e in vy_task_compaction_execute /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1485:9
    tarantool#7 0x5e4ebb73e152 in vy_task_f /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1795:6
    tarantool#8 0x5e4ebb01e0b1 in fiber_cxx_invoke(int (*)(__va_list_tag*), __va_list_tag*) /home/shiny/dev/tarantool/src/lib/core/fiber.h:1331:10
    tarantool#9 0x5e4ebc389ee0 in fiber_loop /home/shiny/dev/tarantool/src/lib/core/fiber.c:1182:18
    tarantool#10 0x5e4ebd3e9595 in coro_init /home/shiny/dev/tarantool/third_party/coro/coro.c:108:3

SUMMARY: AddressSanitizer: 4 byte(s) leaked in 1 allocation(s).
```

Closes tarantool#10489
Part-of tarantool#10211

NO_TEST=covered by existing tests
NO_DOC=bugfix

The issue is we increment `page_count` only on page write. If we fail
for some reason before then page info `min_key` in leaked.

LSAN report for 'vinyl/recovery_quota.test.lua':

```
2024-07-05 13:30:34.605 [478603] main/103/on_shutdown vy_scheduler.c:1668 E> 512/0: failed to compact range (-inf..inf)

=================================================================
==478603==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 4 byte(s) in 1 object(s) allocated from:
    #0 0x5e4ebafcae09 in malloc (/home/shiny/dev/tarantool/build-asan-debug/src/tarantool+0x1244e09) (BuildId: 20c5933d67a3831c4f43f6860379d58d35b81974)
    #1 0x5e4ebb3f9b69 in vy_key_dup /home/shiny/dev/tarantool/src/box/vy_stmt.c:308:14
    #2 0x5e4ebb49b615 in vy_page_info_create /home/shiny/dev/tarantool/src/box/vy_run.c:257:23
    #3 0x5e4ebb48f59f in vy_run_writer_start_page /home/shiny/dev/tarantool/src/box/vy_run.c:2196:6
    #4 0x5e4ebb48c6b6 in vy_run_writer_append_stmt /home/shiny/dev/tarantool/src/box/vy_run.c:2287:6
    #5 0x5e4ebb72877f in vy_task_write_run /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1132:8
    #6 0x5e4ebb73305e in vy_task_compaction_execute /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1485:9
    #7 0x5e4ebb73e152 in vy_task_f /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1795:6
    #8 0x5e4ebb01e0b1 in fiber_cxx_invoke(int (*)(__va_list_tag*), __va_list_tag*) /home/shiny/dev/tarantool/src/lib/core/fiber.h:1331:10
    #9 0x5e4ebc389ee0 in fiber_loop /home/shiny/dev/tarantool/src/lib/core/fiber.c:1182:18
    #10 0x5e4ebd3e9595 in coro_init /home/shiny/dev/tarantool/third_party/coro/coro.c:108:3

SUMMARY: AddressSanitizer: 4 byte(s) leaked in 1 allocation(s).
```

Closes #10489
Part-of #10211

NO_TEST=covered by existing tests
NO_DOC=bugfix

The issue is we increment `page_count` only on page write. If we fail
for some reason before then page info `min_key` in leaked.

LSAN report for 'vinyl/recovery_quota.test.lua':

```
2024-07-05 13:30:34.605 [478603] main/103/on_shutdown vy_scheduler.c:1668 E> 512/0: failed to compact range (-inf..inf)

=================================================================
==478603==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 4 byte(s) in 1 object(s) allocated from:
    #0 0x5e4ebafcae09 in malloc (/home/shiny/dev/tarantool/build-asan-debug/src/tarantool+0x1244e09) (BuildId: 20c5933d67a3831c4f43f6860379d58d35b81974)
    #1 0x5e4ebb3f9b69 in vy_key_dup /home/shiny/dev/tarantool/src/box/vy_stmt.c:308:14
    #2 0x5e4ebb49b615 in vy_page_info_create /home/shiny/dev/tarantool/src/box/vy_run.c:257:23
    #3 0x5e4ebb48f59f in vy_run_writer_start_page /home/shiny/dev/tarantool/src/box/vy_run.c:2196:6
    #4 0x5e4ebb48c6b6 in vy_run_writer_append_stmt /home/shiny/dev/tarantool/src/box/vy_run.c:2287:6
    #5 0x5e4ebb72877f in vy_task_write_run /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1132:8
    #6 0x5e4ebb73305e in vy_task_compaction_execute /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1485:9
    #7 0x5e4ebb73e152 in vy_task_f /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1795:6
    #8 0x5e4ebb01e0b1 in fiber_cxx_invoke(int (*)(__va_list_tag*), __va_list_tag*) /home/shiny/dev/tarantool/src/lib/core/fiber.h:1331:10
    #9 0x5e4ebc389ee0 in fiber_loop /home/shiny/dev/tarantool/src/lib/core/fiber.c:1182:18
    #10 0x5e4ebd3e9595 in coro_init /home/shiny/dev/tarantool/third_party/coro/coro.c:108:3

SUMMARY: AddressSanitizer: 4 byte(s) leaked in 1 allocation(s).
```

Closes #10489
Part-of #10211

NO_TEST=covered by existing tests
NO_DOC=bugfix

(cherry picked from commit 84101f6)

The issue is we increment `page_count` only on page write. If we fail
for some reason before then page info `min_key` in leaked.

LSAN report for 'vinyl/recovery_quota.test.lua':

```
2024-07-05 13:30:34.605 [478603] main/103/on_shutdown vy_scheduler.c:1668 E> 512/0: failed to compact range (-inf..inf)

=================================================================
==478603==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 4 byte(s) in 1 object(s) allocated from:
    #0 0x5e4ebafcae09 in malloc (/home/shiny/dev/tarantool/build-asan-debug/src/tarantool+0x1244e09) (BuildId: 20c5933d67a3831c4f43f6860379d58d35b81974)
    #1 0x5e4ebb3f9b69 in vy_key_dup /home/shiny/dev/tarantool/src/box/vy_stmt.c:308:14
    #2 0x5e4ebb49b615 in vy_page_info_create /home/shiny/dev/tarantool/src/box/vy_run.c:257:23
    #3 0x5e4ebb48f59f in vy_run_writer_start_page /home/shiny/dev/tarantool/src/box/vy_run.c:2196:6
    #4 0x5e4ebb48c6b6 in vy_run_writer_append_stmt /home/shiny/dev/tarantool/src/box/vy_run.c:2287:6
    #5 0x5e4ebb72877f in vy_task_write_run /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1132:8
    #6 0x5e4ebb73305e in vy_task_compaction_execute /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1485:9
    #7 0x5e4ebb73e152 in vy_task_f /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1795:6
    #8 0x5e4ebb01e0b1 in fiber_cxx_invoke(int (*)(__va_list_tag*), __va_list_tag*) /home/shiny/dev/tarantool/src/lib/core/fiber.h:1331:10
    #9 0x5e4ebc389ee0 in fiber_loop /home/shiny/dev/tarantool/src/lib/core/fiber.c:1182:18
    #10 0x5e4ebd3e9595 in coro_init /home/shiny/dev/tarantool/third_party/coro/coro.c:108:3

SUMMARY: AddressSanitizer: 4 byte(s) leaked in 1 allocation(s).
```

Closes #10489
Part-of #10211

NO_TEST=covered by existing tests
NO_DOC=bugfix

(cherry picked from commit 84101f6)

Crash the program after printing the first error report (WARNING: USE AT YOUR OWN RISK!). The flag has effect only if code was compiled with -fsanitize-recover=address compile option.

```
 [061] replication/tarantoolgh-5430-cluster-mvcc.test.lua                     [ pass ]
[050]
[050]
[050] [Instance "box" returns with non-zero exit code: 1]
[050]
[050] [test-run server "box"] Last 15 lines of the log file /tmp/t/050_box/box.log:
[050]     tarantool#9 0x55d6c6868851  (<unknown module>)
[050]
[050] Direct leak of 342 byte(s) in 5 object(s) allocated from:
[050]     #0 0x55d69b184cae in malloc (/__w/tarantool/tarantool/src/tarantool+0x1268cae) (BuildId: 4f3fed4334a726219fb69119e67d451f0cb1ccfa)
[050]     tarantool#1 0x55d69d50040c in small_asan_alloc /__w/tarantool/tarantool/src/lib/small/small/util.c:94:24
[050]     tarantool#2 0x55d69d4fcb3c in smalloc /__w/tarantool/tarantool/src/lib/small/small/small_asan.c:57:5
[050]     tarantool#3 0x55d69ce3782f in runtime_tuple_new /__w/tarantool/tarantool/src/box/tuple.c:138:27
[050]     tarantool#4 0x55d69ce33fac in tuple_new /__w/tarantool/tarantool/src/box/tuple.h:801:9
[050]     tarantool#5 0x55d69ce34844 in box_tuple_new /__w/tarantool/tarantool/src/box/tuple.c:845:22
[050]     tarantool#6 0x55d69b523021 in session_settings_index_get /__w/tarantool/tarantool/src/box/session_settings.c:261:12
[050]     tarantool#7 0x55d69b284077 in index_get(index*, char const*, unsigned int, tuple**) /__w/tarantool/tarantool/src/box/index.h:909:9
[050]     tarantool#8 0x55d69b282794 in box_index_get /__w/tarantool/tarantool/src/box/index.cc:390:11
[050]     tarantool#9 0x55d6c685ea09  (<unknown module>)
[050]
[050] SUMMARY: AddressSanitizer: 5627 byte(s) leaked in 83 allocation(s).
[055] box-luatest/gh_8530_alter_space_snapshot_test.>               [ pass ]
```

1. https://github.com/tarantool/tarantool/actions/runs/10454868034/job/28948757147?pr=10431
2. https://github.com/google/sanitizers/wiki/AddressSanitizerFlags

NO_CHANGELOG=internal
NO_DOC=internal
NO_TEST=internal

Crash the program after printing the first error report (WARNING: USE AT YOUR OWN RISK!). The flag has effect only if code was compiled with -fsanitize-recover=address compile option.

```
 [061] replication/tarantoolgh-5430-cluster-mvcc.test.lua                     [ pass ]
[050]
[050]
[050] [Instance "box" returns with non-zero exit code: 1]
[050]
[050] [test-run server "box"] Last 15 lines of the log file /tmp/t/050_box/box.log:
[050]     tarantool#9 0x55d6c6868851  (<unknown module>)
[050]
[050] Direct leak of 342 byte(s) in 5 object(s) allocated from:
[050]     #0 0x55d69b184cae in malloc (/__w/tarantool/tarantool/src/tarantool+0x1268cae) (BuildId: 4f3fed4334a726219fb69119e67d451f0cb1ccfa)
[050]     tarantool#1 0x55d69d50040c in small_asan_alloc /__w/tarantool/tarantool/src/lib/small/small/util.c:94:24
[050]     tarantool#2 0x55d69d4fcb3c in smalloc /__w/tarantool/tarantool/src/lib/small/small/small_asan.c:57:5
[050]     tarantool#3 0x55d69ce3782f in runtime_tuple_new /__w/tarantool/tarantool/src/box/tuple.c:138:27
[050]     tarantool#4 0x55d69ce33fac in tuple_new /__w/tarantool/tarantool/src/box/tuple.h:801:9
[050]     tarantool#5 0x55d69ce34844 in box_tuple_new /__w/tarantool/tarantool/src/box/tuple.c:845:22
[050]     tarantool#6 0x55d69b523021 in session_settings_index_get /__w/tarantool/tarantool/src/box/session_settings.c:261:12
[050]     tarantool#7 0x55d69b284077 in index_get(index*, char const*, unsigned int, tuple**) /__w/tarantool/tarantool/src/box/index.h:909:9
[050]     tarantool#8 0x55d69b282794 in box_index_get /__w/tarantool/tarantool/src/box/index.cc:390:11
[050]     tarantool#9 0x55d6c685ea09  (<unknown module>)
[050]
[050] SUMMARY: AddressSanitizer: 5627 byte(s) leaked in 83 allocation(s).
[055] box-luatest/gh_8530_alter_space_snapshot_test.>               [ pass ]
```

1. https://github.com/tarantool/tarantool/actions/runs/10454868034/job/28948757147?pr=10431
2. https://github.com/google/sanitizers/wiki/AddressSanitizerFlags

NO_CHANGELOG=internal
NO_DOC=internal
NO_TEST=internal

The reason is that the previous libcurl submodule update in commit
0919f39 ("third_party: update libcurl from
8.8.0 to 8.10.1") reveals the following regression:

NOWRAP
```c
$ tarantool -e "require('http.client').new():get('https://google.com') collectgarbage()"
tarantool: ./third_party/curl/lib/multi.c:3691: curl_multi_assign: Assertion `!(multi)' failed.
Aborted (core dumped)
```
NOWRAP

The stacktrace is the following:

NOWRAP
```c
<...>
#4  __assert_fail
#5  curl_multi_assign            // <- called by us
#6  curl_multi_sock_cb           // <- this is our callback
#7  Curl_multi_pollset_ev
#8  cpool_update_shutdown_ev
#9  cpool_discard_conn
#10 cpool_close_and_destroy_all
#11 Curl_cpool_destroy
#12 curl_multi_cleanup
#13 curl_env_finish              // <- destroy the multi handle
#14 httpc_env_finish
#15 luaT_httpc_cleanup
#16 lj_BC_FUNCC
#17 gc_call_finalizer
#18 gc_finalize
#19 gc_onestep
#20 lj_gc_fullgc
#21 lua_gc
#22 lj_cf_collectgarbage
#23 lj_BC_FUNCC
#24 lua_pcall
#25 luaT_call
#26 lua_main
#27 run_script_f
#28 fiber_cxx_invoke
#29 fiber_loop
#30 coro_init
```
NOWRAP

The multi handle is during the destroy, but our
`CURLMOPT_SOCKETFUNCTION` callback is invoked and the
`curl_multi_assign()` call (invoked to associate a libev watcher to the
given file descriptor) fails on the assertion. Everything is as
described in curl/curl#15201.

The first bad libcurl's commit is [curl-8_10_0-4-g48f61e781][1], but
later it was fixed in [curl-8_10_1-241-g461ce6c61][2]. This commit
updates libcurl to this revision to fix the regression.

Adjusted build options in our build script:

* Added `CURL_DISABLE_IPFS=ON`: [curl-8_10_1-57-gce7d0d413][3]
* Added `CURL_TEST_BUNDLES=OFF`: [curl-8_10_1-67-g71cf0d1fc][4]
* Changed `ENABLE_WEBSOCKETS=OFF` to `CURL_DISABLE_WEBSOCKETS=ON`:
  [curl-8_10_1-130-gd78e129d5][5]

[1]: curl/curl@48f61e7
[2]: curl/curl@461ce6c
[3]: curl/curl@ce7d0d4
[4]: curl/curl@71cf0d1
[5]: curl/curl@d78e129

NO_DOC=bugfix
NO_CHANGELOG=fixes an unreleased commit
NO_TEST=can't reproduce without https to add a test case, verified
        locally

The reason is that the previous libcurl submodule update in commit
0919f39 ("third_party: update libcurl from
8.8.0 to 8.10.1") reveals the following regression:

NOWRAP
```c
$ tarantool -e "require('http.client').new():get('https://google.com') collectgarbage()"
tarantool: ./third_party/curl/lib/multi.c:3691: curl_multi_assign: Assertion `!(multi)' failed.
Aborted (core dumped)
```
NOWRAP

The stacktrace is the following:

NOWRAP
```c
<...>
#4  __assert_fail
#5  curl_multi_assign            // <- called by us
#6  curl_multi_sock_cb           // <- this is our callback
#7  Curl_multi_pollset_ev
#8  cpool_update_shutdown_ev
#9  cpool_discard_conn
#10 cpool_close_and_destroy_all
#11 Curl_cpool_destroy
#12 curl_multi_cleanup
#13 curl_env_finish              // <- destroy the multi handle
#14 httpc_env_finish
#15 luaT_httpc_cleanup
#16 lj_BC_FUNCC
#17 gc_call_finalizer
#18 gc_finalize
#19 gc_onestep
#20 lj_gc_fullgc
#21 lua_gc
#22 lj_cf_collectgarbage
#23 lj_BC_FUNCC
#24 lua_pcall
#25 luaT_call
#26 lua_main
#27 run_script_f
#28 fiber_cxx_invoke
#29 fiber_loop
#30 coro_init
```
NOWRAP

The multi handle is during the destroy, but our
`CURLMOPT_SOCKETFUNCTION` callback is invoked and the
`curl_multi_assign()` call (invoked to associate a libev watcher to the
given file descriptor) fails on the assertion. Everything is as
described in curl/curl#15201.

The first bad libcurl's commit is [curl-8_10_0-4-g48f61e781][1], but
later it was fixed in [curl-8_10_1-241-g461ce6c61][2]. This commit
updates libcurl to this revision to fix the regression.

Adjusted build options in our build script:

* Added `CURL_DISABLE_IPFS=ON`: [curl-8_10_1-57-gce7d0d413][3]
* Added `CURL_TEST_BUNDLES=OFF`: [curl-8_10_1-67-g71cf0d1fc][4]
* Changed `ENABLE_WEBSOCKETS=OFF` to `CURL_DISABLE_WEBSOCKETS=ON`:
  [curl-8_10_1-130-gd78e129d5][5]

[1]: curl/curl@48f61e7
[2]: curl/curl@461ce6c
[3]: curl/curl@ce7d0d4
[4]: curl/curl@71cf0d1
[5]: curl/curl@d78e129

NO_DOC=bugfix
NO_CHANGELOG=fixes an unreleased commit
NO_TEST=can't reproduce without https to add a test case, verified
        locally

The reason is that the previous libcurl submodule update in commit
0919f39 ("third_party: update libcurl from
8.8.0 to 8.10.1") reveals the following regression:

NOWRAP
```c
$ tarantool -e "require('http.client').new():get('https://google.com') collectgarbage()"
tarantool: ./third_party/curl/lib/multi.c:3691: curl_multi_assign: Assertion `!(multi)' failed.
Aborted (core dumped)
```
NOWRAP

The stacktrace is the following:

NOWRAP
```c
<...>
#4  __assert_fail
#5  curl_multi_assign            // <- called by us
#6  curl_multi_sock_cb           // <- this is our callback
#7  Curl_multi_pollset_ev
#8  cpool_update_shutdown_ev
#9  cpool_discard_conn
#10 cpool_close_and_destroy_all
#11 Curl_cpool_destroy
#12 curl_multi_cleanup
#13 curl_env_finish              // <- destroy the multi handle
#14 httpc_env_finish
#15 luaT_httpc_cleanup
#16 lj_BC_FUNCC
#17 gc_call_finalizer
#18 gc_finalize
#19 gc_onestep
#20 lj_gc_fullgc
#21 lua_gc
#22 lj_cf_collectgarbage
#23 lj_BC_FUNCC
#24 lua_pcall
#25 luaT_call
#26 lua_main
#27 run_script_f
#28 fiber_cxx_invoke
#29 fiber_loop
#30 coro_init
```
NOWRAP

The multi handle is during the destroy, but our
`CURLMOPT_SOCKETFUNCTION` callback is invoked and the
`curl_multi_assign()` call (invoked to associate a libev watcher to the
given file descriptor) fails on the assertion. Everything is as
described in curl/curl#15201.

The first bad libcurl's commit is [curl-8_10_0-4-g48f61e781][1], but
later it was fixed in [curl-8_10_1-241-g461ce6c61][2]. This commit
updates libcurl to this revision to fix the regression.

Adjusted build options in our build script:

* Added `CURL_DISABLE_IPFS=ON`: [curl-8_10_1-57-gce7d0d413][3]
* Added `CURL_TEST_BUNDLES=OFF`: [curl-8_10_1-67-g71cf0d1fc][4]
* Changed `ENABLE_WEBSOCKETS=OFF` to `CURL_DISABLE_WEBSOCKETS=ON`:
  [curl-8_10_1-130-gd78e129d5][5]

[1]: curl/curl@48f61e7
[2]: curl/curl@461ce6c
[3]: curl/curl@ce7d0d4
[4]: curl/curl@71cf0d1
[5]: curl/curl@d78e129

NO_DOC=bugfix
NO_CHANGELOG=fixes an unreleased commit
NO_TEST=can't reproduce without https to add a test case, verified
        locally

The reason is that the previous libcurl submodule update in commit
0919f39 ("third_party: update libcurl from
8.8.0 to 8.10.1") reveals the following regression:

NOWRAP
```c
$ tarantool -e "require('http.client').new():get('https://google.com') collectgarbage()"
tarantool: ./third_party/curl/lib/multi.c:3691: curl_multi_assign: Assertion `!(multi)' failed.
Aborted (core dumped)
```
NOWRAP

The stacktrace is the following:

NOWRAP
```c
<...>
#4  __assert_fail
#5  curl_multi_assign            // <- called by us
#6  curl_multi_sock_cb           // <- this is our callback
#7  Curl_multi_pollset_ev
#8  cpool_update_shutdown_ev
#9  cpool_discard_conn
#10 cpool_close_and_destroy_all
#11 Curl_cpool_destroy
#12 curl_multi_cleanup
#13 curl_env_finish              // <- destroy the multi handle
#14 httpc_env_finish
#15 luaT_httpc_cleanup
#16 lj_BC_FUNCC
#17 gc_call_finalizer
#18 gc_finalize
#19 gc_onestep
#20 lj_gc_fullgc
#21 lua_gc
#22 lj_cf_collectgarbage
#23 lj_BC_FUNCC
#24 lua_pcall
#25 luaT_call
#26 lua_main
#27 run_script_f
#28 fiber_cxx_invoke
#29 fiber_loop
#30 coro_init
```
NOWRAP

The multi handle is during the destroy, but our
`CURLMOPT_SOCKETFUNCTION` callback is invoked and the
`curl_multi_assign()` call (invoked to associate a libev watcher to the
given file descriptor) fails on the assertion. Everything is as
described in curl/curl#15201.

The first bad libcurl's commit is [curl-8_10_0-4-g48f61e781][1], but
later it was fixed in [curl-8_10_1-241-g461ce6c61][2]. This commit
updates libcurl to this revision to fix the regression.

Adjusted build options in our build script:

* Added `CURL_DISABLE_IPFS=ON`: [curl-8_10_1-57-gce7d0d413][3]
* Added `CURL_TEST_BUNDLES=OFF`: [curl-8_10_1-67-g71cf0d1fc][4]
* Changed `ENABLE_WEBSOCKETS=OFF` to `CURL_DISABLE_WEBSOCKETS=ON`:
  [curl-8_10_1-130-gd78e129d5][5]

[1]: curl/curl@48f61e7
[2]: curl/curl@461ce6c
[3]: curl/curl@ce7d0d4
[4]: curl/curl@71cf0d1
[5]: curl/curl@d78e129

NO_DOC=bugfix
NO_CHANGELOG=fixes an unreleased commit
NO_TEST=can't reproduce without https to add a test case, verified
        locally

(cherry picked from commit fbe6d0a)

The reason is that the previous libcurl submodule update in commit
0919f39 ("third_party: update libcurl from
8.8.0 to 8.10.1") reveals the following regression:

NOWRAP
```c
$ tarantool -e "require('http.client').new():get('https://google.com') collectgarbage()"
tarantool: ./third_party/curl/lib/multi.c:3691: curl_multi_assign: Assertion `!(multi)' failed.
Aborted (core dumped)
```
NOWRAP

The stacktrace is the following:

NOWRAP
```c
<...>
#4  __assert_fail
#5  curl_multi_assign            // <- called by us
#6  curl_multi_sock_cb           // <- this is our callback
#7  Curl_multi_pollset_ev
#8  cpool_update_shutdown_ev
#9  cpool_discard_conn
#10 cpool_close_and_destroy_all
#11 Curl_cpool_destroy
#12 curl_multi_cleanup
#13 curl_env_finish              // <- destroy the multi handle
#14 httpc_env_finish
#15 luaT_httpc_cleanup
#16 lj_BC_FUNCC
#17 gc_call_finalizer
#18 gc_finalize
#19 gc_onestep
#20 lj_gc_fullgc
#21 lua_gc
#22 lj_cf_collectgarbage
#23 lj_BC_FUNCC
#24 lua_pcall
#25 luaT_call
#26 lua_main
#27 run_script_f
#28 fiber_cxx_invoke
#29 fiber_loop
#30 coro_init
```
NOWRAP

The multi handle is during the destroy, but our
`CURLMOPT_SOCKETFUNCTION` callback is invoked and the
`curl_multi_assign()` call (invoked to associate a libev watcher to the
given file descriptor) fails on the assertion. Everything is as
described in curl/curl#15201.

The first bad libcurl's commit is [curl-8_10_0-4-g48f61e781][1], but
later it was fixed in [curl-8_10_1-241-g461ce6c61][2]. This commit
updates libcurl to this revision to fix the regression.

Adjusted build options in our build script:

* Added `CURL_DISABLE_IPFS=ON`: [curl-8_10_1-57-gce7d0d413][3]
* Added `CURL_TEST_BUNDLES=OFF`: [curl-8_10_1-67-g71cf0d1fc][4]
* Changed `ENABLE_WEBSOCKETS=OFF` to `CURL_DISABLE_WEBSOCKETS=ON`:
  [curl-8_10_1-130-gd78e129d5][5]

[1]: curl/curl@48f61e7
[2]: curl/curl@461ce6c
[3]: curl/curl@ce7d0d4
[4]: curl/curl@71cf0d1
[5]: curl/curl@d78e129

NO_DOC=bugfix
NO_CHANGELOG=fixes an unreleased commit
NO_TEST=can't reproduce without https to add a test case, verified
        locally

(cherry picked from commit fbe6d0a)

The reason is that the previous libcurl submodule update in commit
0919f39 ("third_party: update libcurl from
8.8.0 to 8.10.1") reveals the following regression:

NOWRAP
```c
$ tarantool -e "require('http.client').new():get('https://google.com') collectgarbage()"
tarantool: ./third_party/curl/lib/multi.c:3691: curl_multi_assign: Assertion `!(multi)' failed.
Aborted (core dumped)
```
NOWRAP

The stacktrace is the following:

NOWRAP
```c
<...>
#4  __assert_fail
#5  curl_multi_assign            // <- called by us
#6  curl_multi_sock_cb           // <- this is our callback
#7  Curl_multi_pollset_ev
#8  cpool_update_shutdown_ev
#9  cpool_discard_conn
#10 cpool_close_and_destroy_all
#11 Curl_cpool_destroy
#12 curl_multi_cleanup
#13 curl_env_finish              // <- destroy the multi handle
#14 httpc_env_finish
#15 luaT_httpc_cleanup
#16 lj_BC_FUNCC
#17 gc_call_finalizer
#18 gc_finalize
#19 gc_onestep
#20 lj_gc_fullgc
#21 lua_gc
#22 lj_cf_collectgarbage
#23 lj_BC_FUNCC
#24 lua_pcall
#25 luaT_call
#26 lua_main
#27 run_script_f
#28 fiber_cxx_invoke
#29 fiber_loop
#30 coro_init
```
NOWRAP

The multi handle is during the destroy, but our
`CURLMOPT_SOCKETFUNCTION` callback is invoked and the
`curl_multi_assign()` call (invoked to associate a libev watcher to the
given file descriptor) fails on the assertion. Everything is as
described in curl/curl#15201.

The first bad libcurl's commit is [curl-8_10_0-4-g48f61e781][1], but
later it was fixed in [curl-8_10_1-241-g461ce6c61][2]. This commit
updates libcurl to this revision to fix the regression.

Adjusted build options in our build script:

* Added `CURL_DISABLE_IPFS=ON`: [curl-8_10_1-57-gce7d0d413][3]
* Added `CURL_TEST_BUNDLES=OFF`: [curl-8_10_1-67-g71cf0d1fc][4]
* Changed `ENABLE_WEBSOCKETS=OFF` to `CURL_DISABLE_WEBSOCKETS=ON`:
  [curl-8_10_1-130-gd78e129d5][5]

[1]: curl/curl@48f61e7
[2]: curl/curl@461ce6c
[3]: curl/curl@ce7d0d4
[4]: curl/curl@71cf0d1
[5]: curl/curl@d78e129

NO_DOC=bugfix
NO_CHANGELOG=fixes an unreleased commit
NO_TEST=can't reproduce without https to add a test case, verified
        locally

(cherry picked from commit fbe6d0a)

The reason is that the previous libcurl submodule update in commit
0919f39 ("third_party: update libcurl from
8.8.0 to 8.10.1") reveals the following regression:

NOWRAP
```c
$ tarantool -e "require('http.client').new():get('https://google.com') collectgarbage()"
tarantool: ./third_party/curl/lib/multi.c:3691: curl_multi_assign: Assertion `!(multi)' failed.
Aborted (core dumped)
```
NOWRAP

The stacktrace is the following:

NOWRAP
```c
<...>
#4  __assert_fail
#5  curl_multi_assign            // <- called by us
#6  curl_multi_sock_cb           // <- this is our callback
#7  Curl_multi_pollset_ev
#8  cpool_update_shutdown_ev
#9  cpool_discard_conn
#10 cpool_close_and_destroy_all
#11 Curl_cpool_destroy
#12 curl_multi_cleanup
#13 curl_env_finish              // <- destroy the multi handle
#14 httpc_env_finish
#15 luaT_httpc_cleanup
#16 lj_BC_FUNCC
#17 gc_call_finalizer
#18 gc_finalize
#19 gc_onestep
#20 lj_gc_fullgc
#21 lua_gc
#22 lj_cf_collectgarbage
#23 lj_BC_FUNCC
#24 lua_pcall
#25 luaT_call
#26 lua_main
#27 run_script_f
#28 fiber_cxx_invoke
#29 fiber_loop
#30 coro_init
```
NOWRAP

The multi handle is during the destroy, but our
`CURLMOPT_SOCKETFUNCTION` callback is invoked and the
`curl_multi_assign()` call (invoked to associate a libev watcher to the
given file descriptor) fails on the assertion. Everything is as
described in curl/curl#15201.

The first bad libcurl's commit is [curl-8_10_0-4-g48f61e781][1], but
later it was fixed in [curl-8_10_1-241-g461ce6c61][2]. This commit
updates libcurl to this revision to fix the regression.

Adjusted build options in our build script:

* Added `CURL_DISABLE_IPFS=ON`: [curl-8_10_1-57-gce7d0d413][3]
* Added `CURL_TEST_BUNDLES=OFF`: [curl-8_10_1-67-g71cf0d1fc][4]
* Changed `ENABLE_WEBSOCKETS=OFF` to `CURL_DISABLE_WEBSOCKETS=ON`:
  [curl-8_10_1-130-gd78e129d5][5]

[1]: curl/curl@48f61e7
[2]: curl/curl@461ce6c
[3]: curl/curl@ce7d0d4
[4]: curl/curl@71cf0d1
[5]: curl/curl@d78e129

NO_DOC=bugfix
NO_CHANGELOG=fixes an unreleased commit
NO_TEST=can't reproduce without https to add a test case, verified
        locally

(cherry picked from commit fbe6d0a)

The reason is that the previous libcurl submodule update in commit
0919f39 ("third_party: update libcurl from
8.8.0 to 8.10.1") reveals the following regression:

NOWRAP
```c
$ tarantool -e "require('http.client').new():get('https://google.com') collectgarbage()"
tarantool: ./third_party/curl/lib/multi.c:3691: curl_multi_assign: Assertion `!(multi)' failed.
Aborted (core dumped)
```
NOWRAP

The stacktrace is the following:

NOWRAP
```c
<...>
tarantool#4  __assert_fail
tarantool#5  curl_multi_assign            // <- called by us
tarantool#6  curl_multi_sock_cb           // <- this is our callback
tarantool#7  Curl_multi_pollset_ev
tarantool#8  cpool_update_shutdown_ev
tarantool#9  cpool_discard_conn
tarantool#10 cpool_close_and_destroy_all
tarantool#11 Curl_cpool_destroy
tarantool#12 curl_multi_cleanup
tarantool#13 curl_env_finish              // <- destroy the multi handle
tarantool#14 httpc_env_finish
tarantool#15 luaT_httpc_cleanup
tarantool#16 lj_BC_FUNCC
tarantool#17 gc_call_finalizer
tarantool#18 gc_finalize
tarantool#19 gc_onestep
tarantool#20 lj_gc_fullgc
tarantool#21 lua_gc
tarantool#22 lj_cf_collectgarbage
tarantool#23 lj_BC_FUNCC
tarantool#24 lua_pcall
tarantool#25 luaT_call
tarantool#26 lua_main
tarantool#27 run_script_f
tarantool#28 fiber_cxx_invoke
tarantool#29 fiber_loop
tarantool#30 coro_init
```
NOWRAP

The multi handle is during the destroy, but our
`CURLMOPT_SOCKETFUNCTION` callback is invoked and the
`curl_multi_assign()` call (invoked to associate a libev watcher to the
given file descriptor) fails on the assertion. Everything is as
described in curl/curl#15201.

The first bad libcurl's commit is [curl-8_10_0-4-g48f61e781][1], but
later it was fixed in [curl-8_10_1-241-g461ce6c61][2]. This commit
updates libcurl to this revision to fix the regression.

Adjusted build options in our build script:

* Added `CURL_DISABLE_IPFS=ON`: [curl-8_10_1-57-gce7d0d413][3]
* Added `CURL_TEST_BUNDLES=OFF`: [curl-8_10_1-67-g71cf0d1fc][4]
* Changed `ENABLE_WEBSOCKETS=OFF` to `CURL_DISABLE_WEBSOCKETS=ON`:
  [curl-8_10_1-130-gd78e129d5][5]

[1]: curl/curl@48f61e7
[2]: curl/curl@461ce6c
[3]: curl/curl@ce7d0d4
[4]: curl/curl@71cf0d1
[5]: curl/curl@d78e129

NO_DOC=bugfix
NO_CHANGELOG=fixes an unreleased commit
NO_TEST=can't reproduce without https to add a test case, verified
        locally

After updating clang to 19 and luatest to 1.2.0, running the test
replication-luatest/gh_9399_raft_leader_steps_off_on_ER_WAL_IO_test.lua
reports new memory leaks:

```
=================================================================
==61990==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 584 byte(s) in 1 object(s) allocated from:
    #0 0x55555682416f in malloc (/__w/tarantool/tarantool/src/tarantool+0x12d016f) (BuildId: d7cc65c7fb4ddda974a7803444499d916e007cb1)
    #1 0x555558922aa6 in small_asan_alloc /__w/tarantool/tarantool/src/lib/small/small/util.c:94:24
    #2 0x55555891b920 in region_prepare_buf /__w/tarantool/tarantool/src/lib/small/small/region_asan.c:39:4
    #3 0x55555891c237 in region_aligned_alloc /__w/tarantool/tarantool/src/lib/small/small/region_asan.c:94:14
    #4 0x555557a517fb in fiber_gc_checker_init /__w/tarantool/tarantool/src/lib/core/fiber.c:1542:3
    #5 0x555557a568c3 in cord_create /__w/tarantool/tarantool/src/lib/core/fiber.c:1870:2
    #6 0x555557a5d242 in cord_thread_func /__w/tarantool/tarantool/src/lib/core/fiber.c:1984:2
    #7 0x555556821b26 in asan_thread_start(void*) asan_interceptors.cpp.o

Direct leak of 564 byte(s) in 1 object(s) allocated from:
    #0 0x55555682416f in malloc (/__w/tarantool/tarantool/src/tarantool+0x12d016f) (BuildId: d7cc65c7fb4ddda974a7803444499d916e007cb1)
    #1 0x555558922aa6 in small_asan_alloc /__w/tarantool/tarantool/src/lib/small/small/util.c:94:24
    #2 0x55555891346d in mempool_alloc /__w/tarantool/tarantool/src/lib/small/small/mempool_asan.c:67:4
    #3 0x5555568c8db8 in iproto_msg_new(iproto_connection*) /__w/tarantool/tarantool/src/box/iproto.cc:1010:24
    #4 0x5555568e691d in iproto_thread_accept(iproto_thread*, iostream*, sockaddr*, unsigned int, session*) /__w/tarantool/tarantool/src/box/iproto.cc:3420:27
    #5 0x5555568e687e in iproto_on_accept_cb(evio_service*, iostream*, sockaddr*, unsigned int) /__w/tarantool/tarantool/src/box/iproto.cc:3438:2
    #6 0x555557abc5b5 in evio_service_entry_accept_cb /__w/tarantool/tarantool/src/lib/core/evio.c:207:3
    #7 0x55555896db7b in ev_invoke_pending /__w/tarantool/tarantool/third_party/libev/ev.c:3797:11
    #8 0x55555896f5bd in ev_run /__w/tarantool/tarantool/third_party/libev/ev.c:4221:7
    #9 0x555557a660a6 in cord_costart_thread_func /__w/tarantool/tarantool/src/lib/core/fiber.c:2203:3
    #10 0x555557a5f6ee in cord_thread_func /__w/tarantool/tarantool/src/lib/core/fiber.c:1996:14
    #11 0x555556821b26 in asan_thread_start(void*) asan_interceptors.cpp.o

SUMMARY: AddressSanitizer: 1148 byte(s) leaked in 2 allocation(s).
```

It's unclear what exactly triggered the new leaks detection. Let's file
tickets and add suppressions.

See #10701
See #11740

NO_DOC=lsan
NO_TEST=lsan
NO_CHANGELOG=lsan

After updating clang to 19 and luatest to 1.2.0, running the test
replication-luatest/gh_9399_raft_leader_steps_off_on_ER_WAL_IO_test.lua
reports new memory leaks:

```
=================================================================
==61990==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 584 byte(s) in 1 object(s) allocated from:
    #0 0x55555682416f in malloc (/__w/tarantool/tarantool/src/tarantool+0x12d016f) (BuildId: d7cc65c7fb4ddda974a7803444499d916e007cb1)
    #1 0x555558922aa6 in small_asan_alloc /__w/tarantool/tarantool/src/lib/small/small/util.c:94:24
    #2 0x55555891b920 in region_prepare_buf /__w/tarantool/tarantool/src/lib/small/small/region_asan.c:39:4
    #3 0x55555891c237 in region_aligned_alloc /__w/tarantool/tarantool/src/lib/small/small/region_asan.c:94:14
    #4 0x555557a517fb in fiber_gc_checker_init /__w/tarantool/tarantool/src/lib/core/fiber.c:1542:3
    #5 0x555557a568c3 in cord_create /__w/tarantool/tarantool/src/lib/core/fiber.c:1870:2
    #6 0x555557a5d242 in cord_thread_func /__w/tarantool/tarantool/src/lib/core/fiber.c:1984:2
    #7 0x555556821b26 in asan_thread_start(void*) asan_interceptors.cpp.o

Direct leak of 564 byte(s) in 1 object(s) allocated from:
    #0 0x55555682416f in malloc (/__w/tarantool/tarantool/src/tarantool+0x12d016f) (BuildId: d7cc65c7fb4ddda974a7803444499d916e007cb1)
    #1 0x555558922aa6 in small_asan_alloc /__w/tarantool/tarantool/src/lib/small/small/util.c:94:24
    #2 0x55555891346d in mempool_alloc /__w/tarantool/tarantool/src/lib/small/small/mempool_asan.c:67:4
    #3 0x5555568c8db8 in iproto_msg_new(iproto_connection*) /__w/tarantool/tarantool/src/box/iproto.cc:1010:24
    #4 0x5555568e691d in iproto_thread_accept(iproto_thread*, iostream*, sockaddr*, unsigned int, session*) /__w/tarantool/tarantool/src/box/iproto.cc:3420:27
    #5 0x5555568e687e in iproto_on_accept_cb(evio_service*, iostream*, sockaddr*, unsigned int) /__w/tarantool/tarantool/src/box/iproto.cc:3438:2
    #6 0x555557abc5b5 in evio_service_entry_accept_cb /__w/tarantool/tarantool/src/lib/core/evio.c:207:3
    #7 0x55555896db7b in ev_invoke_pending /__w/tarantool/tarantool/third_party/libev/ev.c:3797:11
    #8 0x55555896f5bd in ev_run /__w/tarantool/tarantool/third_party/libev/ev.c:4221:7
    #9 0x555557a660a6 in cord_costart_thread_func /__w/tarantool/tarantool/src/lib/core/fiber.c:2203:3
    #10 0x555557a5f6ee in cord_thread_func /__w/tarantool/tarantool/src/lib/core/fiber.c:1996:14
    #11 0x555556821b26 in asan_thread_start(void*) asan_interceptors.cpp.o

SUMMARY: AddressSanitizer: 1148 byte(s) leaked in 2 allocation(s).
```

It's unclear what exactly triggered the new leaks detection. Let's file
tickets and add suppressions.

See #10701
See #11740

NO_DOC=lsan
NO_TEST=lsan
NO_CHANGELOG=lsan

After updating clang to 19 and luatest to 1.2.0, running the test
replication-luatest/gh_9399_raft_leader_steps_off_on_ER_WAL_IO_test.lua
reports new memory leaks:

```
=================================================================
==61990==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 584 byte(s) in 1 object(s) allocated from:
    #0 0x55555682416f in malloc (/__w/tarantool/tarantool/src/tarantool+0x12d016f) (BuildId: d7cc65c7fb4ddda974a7803444499d916e007cb1)
    #1 0x555558922aa6 in small_asan_alloc /__w/tarantool/tarantool/src/lib/small/small/util.c:94:24
    #2 0x55555891b920 in region_prepare_buf /__w/tarantool/tarantool/src/lib/small/small/region_asan.c:39:4
    #3 0x55555891c237 in region_aligned_alloc /__w/tarantool/tarantool/src/lib/small/small/region_asan.c:94:14
    #4 0x555557a517fb in fiber_gc_checker_init /__w/tarantool/tarantool/src/lib/core/fiber.c:1542:3
    #5 0x555557a568c3 in cord_create /__w/tarantool/tarantool/src/lib/core/fiber.c:1870:2
    #6 0x555557a5d242 in cord_thread_func /__w/tarantool/tarantool/src/lib/core/fiber.c:1984:2
    #7 0x555556821b26 in asan_thread_start(void*) asan_interceptors.cpp.o

Direct leak of 564 byte(s) in 1 object(s) allocated from:
    #0 0x55555682416f in malloc (/__w/tarantool/tarantool/src/tarantool+0x12d016f) (BuildId: d7cc65c7fb4ddda974a7803444499d916e007cb1)
    #1 0x555558922aa6 in small_asan_alloc /__w/tarantool/tarantool/src/lib/small/small/util.c:94:24
    #2 0x55555891346d in mempool_alloc /__w/tarantool/tarantool/src/lib/small/small/mempool_asan.c:67:4
    #3 0x5555568c8db8 in iproto_msg_new(iproto_connection*) /__w/tarantool/tarantool/src/box/iproto.cc:1010:24
    #4 0x5555568e691d in iproto_thread_accept(iproto_thread*, iostream*, sockaddr*, unsigned int, session*) /__w/tarantool/tarantool/src/box/iproto.cc:3420:27
    #5 0x5555568e687e in iproto_on_accept_cb(evio_service*, iostream*, sockaddr*, unsigned int) /__w/tarantool/tarantool/src/box/iproto.cc:3438:2
    #6 0x555557abc5b5 in evio_service_entry_accept_cb /__w/tarantool/tarantool/src/lib/core/evio.c:207:3
    #7 0x55555896db7b in ev_invoke_pending /__w/tarantool/tarantool/third_party/libev/ev.c:3797:11
    #8 0x55555896f5bd in ev_run /__w/tarantool/tarantool/third_party/libev/ev.c:4221:7
    #9 0x555557a660a6 in cord_costart_thread_func /__w/tarantool/tarantool/src/lib/core/fiber.c:2203:3
    #10 0x555557a5f6ee in cord_thread_func /__w/tarantool/tarantool/src/lib/core/fiber.c:1996:14
    #11 0x555556821b26 in asan_thread_start(void*) asan_interceptors.cpp.o

SUMMARY: AddressSanitizer: 1148 byte(s) leaked in 2 allocation(s).
```

It's unclear what exactly triggered the new leaks detection. Let's file
tickets and add suppressions.

See #10701
See #11740

NO_DOC=lsan
NO_TEST=lsan
NO_CHANGELOG=lsan

Leak sanitizer started detecting new leaks in etcd-client tests in
the enterprise repo. This only happens on 3.2 branch, and must be
due to the fact we haven't backported commits regarding correct Lua
state cleanup on shutdown. Commit 80a11c4 ("box: close Lua state
on exit") in particular.

Since that patch series is rather heavy, let's simply suppress the leak
in 3.2 branch.

The leak in question:
```
Direct leak of 52 byte(s) in 1 object(s) allocated from:
   #0 0x556c873b3aae in malloc (/__w/tarantool-ee/tarantool-ee/tarantool/src/tarantool+0x1573aae) (BuildId: b2a73382837eb52617097838e12bd4d33ce21792)
   tarantool#1 0x556c89ebd8ec in small_asan_alloc /__w/tarantool-ee/tarantool-ee/tarantool/src/lib/small/small/util.c:94:24
   tarantool#2 0x556c89eb5f84 in region_prepare_buf /__w/tarantool-ee/tarantool-ee/tarantool/src/lib/small/small/region_asan.c:39:4
   tarantool#3 0x556c89eb6919 in region_aligned_alloc /__w/tarantool-ee/tarantool-ee/tarantool/src/lib/small/small/region_asan.c:94:14
   tarantool#4 0x556c8895d4b9 in region_alloc /__w/tarantool-ee/tarantool-ee/tarantool/src/lib/small/include/small/region_asan.h:131:9
   tarantool#5 0x556c8894b88a in curl_easy_header_cb /__w/tarantool-ee/tarantool-ee/tarantool/src/httpc.c:124:12
   tarantool#6 0x556c89477809 in cw_out_ptr_flush /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/cw-out.c:223:16
   tarantool#7 0x556c89477364 in cw_out_do_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/cw-out.c:377:14
   tarantool#8 0x556c89476df4 in cw_out_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/cw-out.c:415:14
   tarantool#9 0x556c894bab21 in Curl_cwriter_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/sendf.c:183:10
   tarantool#10 0x556c894bc525 in cw_download_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/sendf.c:253:14
   tarantool#11 0x556c894bab21 in Curl_cwriter_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/sendf.c:183:10
   tarantool#12 0x556c8948578e in hds_cw_collect_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/headers.c:367:10
   tarantool#13 0x556c894bab21 in Curl_cwriter_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/sendf.c:183:10
   tarantool#14 0x556c894bcb6d in cw_raw_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/sendf.c:367:10
   tarantool#15 0x556c894bab21 in Curl_cwriter_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/sendf.c:183:10
   tarantool#16 0x556c894ba8fe in Curl_client_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/sendf.c:91:12
   tarantool#17 0x556c89493ab4 in http_write_header /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/http.c:3363:12
   tarantool#18 0x556c89492fab in http_on_response /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/http.c:3399:14
   tarantool#19 0x556c894909fe in http_rw_hd /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/http.c:3688:14
   tarantool#20 0x556c894918b2 in http_parse_headers /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/http.c:3929:14
   tarantool#21 0x556c894913f9 in Curl_http_write_resp_hds /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/http.c:3986:14
   tarantool#22 0x556c8948a3af in Curl_http_write_resp /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/http.c:4010:12
   tarantool#23 0x556c894d6385 in Curl_xfer_write_resp /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/transfer.c:1168:14
   tarantool#24 0x556c894d45b4 in sendrecv_dl /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/transfer.c:343:14
   tarantool#25 0x556c894d3eb3 in Curl_sendrecv /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/transfer.c:451:14
   tarantool#26 0x556c894af0b0 in multi_runsingle /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/multi.c:2374:16
   tarantool#27 0x556c894b388a in multi_run_expired /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/multi.c:3151:14
   tarantool#28 0x556c894b15d4 in multi_socket /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/multi.c:3234:12
   tarantool#29 0x556c894b1701 in curl_multi_socket_action /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/multi.c:3358:10
```

In scope of tarantool/tarantool-ee#1407

NO_DOC=lsan
NO_TEST=lsan
NO_CHANGELOG=lsan

Leak sanitizer started detecting new leaks in etcd-client tests in
the enterprise repo. This only happens on 3.2 branch, and must be
due to the fact we haven't backported commits regarding correct Lua
state cleanup on shutdown. Commit 80a11c4 ("box: close Lua state
on exit") in particular.

Since that patch series is rather heavy, let's simply suppress the leak
in 3.2 branch.

The leak in question:
```
Direct leak of 52 byte(s) in 1 object(s) allocated from:
   #0 0x556c873b3aae in malloc (/__w/tarantool-ee/tarantool-ee/tarantool/src/tarantool+0x1573aae) (BuildId: b2a73382837eb52617097838e12bd4d33ce21792)
   tarantool#1 0x556c89ebd8ec in small_asan_alloc /__w/tarantool-ee/tarantool-ee/tarantool/src/lib/small/small/util.c:94:24
   tarantool#2 0x556c89eb5f84 in region_prepare_buf /__w/tarantool-ee/tarantool-ee/tarantool/src/lib/small/small/region_asan.c:39:4
   tarantool#3 0x556c89eb6919 in region_aligned_alloc /__w/tarantool-ee/tarantool-ee/tarantool/src/lib/small/small/region_asan.c:94:14
   tarantool#4 0x556c8895d4b9 in region_alloc /__w/tarantool-ee/tarantool-ee/tarantool/src/lib/small/include/small/region_asan.h:131:9
   tarantool#5 0x556c8894b88a in curl_easy_header_cb /__w/tarantool-ee/tarantool-ee/tarantool/src/httpc.c:124:12
   tarantool#6 0x556c89477809 in cw_out_ptr_flush /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/cw-out.c:223:16
   tarantool#7 0x556c89477364 in cw_out_do_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/cw-out.c:377:14
   tarantool#8 0x556c89476df4 in cw_out_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/cw-out.c:415:14
   tarantool#9 0x556c894bab21 in Curl_cwriter_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/sendf.c:183:10
   tarantool#10 0x556c894bc525 in cw_download_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/sendf.c:253:14
   tarantool#11 0x556c894bab21 in Curl_cwriter_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/sendf.c:183:10
   tarantool#12 0x556c8948578e in hds_cw_collect_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/headers.c:367:10
   tarantool#13 0x556c894bab21 in Curl_cwriter_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/sendf.c:183:10
   tarantool#14 0x556c894bcb6d in cw_raw_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/sendf.c:367:10
   tarantool#15 0x556c894bab21 in Curl_cwriter_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/sendf.c:183:10
   tarantool#16 0x556c894ba8fe in Curl_client_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/sendf.c:91:12
   tarantool#17 0x556c89493ab4 in http_write_header /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/http.c:3363:12
   tarantool#18 0x556c89492fab in http_on_response /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/http.c:3399:14
   tarantool#19 0x556c894909fe in http_rw_hd /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/http.c:3688:14
   tarantool#20 0x556c894918b2 in http_parse_headers /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/http.c:3929:14
   tarantool#21 0x556c894913f9 in Curl_http_write_resp_hds /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/http.c:3986:14
   tarantool#22 0x556c8948a3af in Curl_http_write_resp /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/http.c:4010:12
   tarantool#23 0x556c894d6385 in Curl_xfer_write_resp /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/transfer.c:1168:14
   tarantool#24 0x556c894d45b4 in sendrecv_dl /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/transfer.c:343:14
   tarantool#25 0x556c894d3eb3 in Curl_sendrecv /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/transfer.c:451:14
   tarantool#26 0x556c894af0b0 in multi_runsingle /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/multi.c:2374:16
   tarantool#27 0x556c894b388a in multi_run_expired /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/multi.c:3151:14
   tarantool#28 0x556c894b15d4 in multi_socket /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/multi.c:3234:12
   tarantool#29 0x556c894b1701 in curl_multi_socket_action /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/multi.c:3358:10
```

In scope of tarantool/tarantool-ee#1407

NO_DOC=lsan
NO_TEST=lsan
NO_CHANGELOG=lsan

Leak sanitizer started detecting new leaks in etcd-client tests in
the enterprise repo. This only happens on 3.2 branch, and must be
due to the fact we haven't backported commits regarding correct Lua
state cleanup on shutdown. Commit 80a11c4 ("box: close Lua state
on exit") in particular.

Since that patch series is rather heavy, let's simply suppress the leak
in 3.2 branch.

The leaks in question:
```
Direct leak of 52 byte(s) in 1 object(s) allocated from:
   #0 0x556c873b3aae in malloc (/__w/tarantool-ee/tarantool-ee/tarantool/src/tarantool+0x1573aae) (BuildId: b2a73382837eb52617097838e12bd4d33ce21792)
   tarantool#1 0x556c89ebd8ec in small_asan_alloc /__w/tarantool-ee/tarantool-ee/tarantool/src/lib/small/small/util.c:94:24
   tarantool#2 0x556c89eb5f84 in region_prepare_buf /__w/tarantool-ee/tarantool-ee/tarantool/src/lib/small/small/region_asan.c:39:4
   tarantool#3 0x556c89eb6919 in region_aligned_alloc /__w/tarantool-ee/tarantool-ee/tarantool/src/lib/small/small/region_asan.c:94:14
   tarantool#4 0x556c8895d4b9 in region_alloc /__w/tarantool-ee/tarantool-ee/tarantool/src/lib/small/include/small/region_asan.h:131:9
   tarantool#5 0x556c8894b88a in curl_easy_header_cb /__w/tarantool-ee/tarantool-ee/tarantool/src/httpc.c:124:12
   tarantool#6 0x556c89477809 in cw_out_ptr_flush /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/cw-out.c:223:16
   tarantool#7 0x556c89477364 in cw_out_do_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/cw-out.c:377:14
   tarantool#8 0x556c89476df4 in cw_out_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/cw-out.c:415:14
   tarantool#9 0x556c894bab21 in Curl_cwriter_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/sendf.c:183:10
   tarantool#10 0x556c894bc525 in cw_download_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/sendf.c:253:14
   tarantool#11 0x556c894bab21 in Curl_cwriter_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/sendf.c:183:10
   tarantool#12 0x556c8948578e in hds_cw_collect_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/headers.c:367:10
   tarantool#13 0x556c894bab21 in Curl_cwriter_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/sendf.c:183:10
   tarantool#14 0x556c894bcb6d in cw_raw_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/sendf.c:367:10
   tarantool#15 0x556c894bab21 in Curl_cwriter_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/sendf.c:183:10
   tarantool#16 0x556c894ba8fe in Curl_client_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/sendf.c:91:12
   tarantool#17 0x556c89493ab4 in http_write_header /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/http.c:3363:12
   tarantool#18 0x556c89492fab in http_on_response /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/http.c:3399:14
   tarantool#19 0x556c894909fe in http_rw_hd /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/http.c:3688:14
   tarantool#20 0x556c894918b2 in http_parse_headers /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/http.c:3929:14
   tarantool#21 0x556c894913f9 in Curl_http_write_resp_hds /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/http.c:3986:14
   tarantool#22 0x556c8948a3af in Curl_http_write_resp /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/http.c:4010:12
   tarantool#23 0x556c894d6385 in Curl_xfer_write_resp /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/transfer.c:1168:14
   tarantool#24 0x556c894d45b4 in sendrecv_dl /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/transfer.c:343:14
   tarantool#25 0x556c894d3eb3 in Curl_sendrecv /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/transfer.c:451:14
   tarantool#26 0x556c894af0b0 in multi_runsingle /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/multi.c:2374:16
   tarantool#27 0x556c894b388a in multi_run_expired /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/multi.c:3151:14
   tarantool#28 0x556c894b15d4 in multi_socket /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/multi.c:3234:12
   tarantool#29 0x556c894b1701 in curl_multi_socket_action /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/multi.c:3358:10

Direct leak of 843 byte(s) in 10 object(s) allocated from:
    #0 0x55b5b99cf745 in malloc (/home/shiny/dev/tarantool-ee/build-asan-release/tarantool/src/tarantool+0x3c7745) (BuildId: 5734aabea48158206be8be71e45f2c40edd09a4b)
    tarantool#1 0x55b5ba4c6c9a in small_asan_alloc /home/shiny/dev/tarantool-ee/tarantool/src/lib/small/small/util.c:94:24
    tarantool#2 0x55b5ba4c5c42 in region_prepare_buf /home/shiny/dev/tarantool-ee/tarantool/src/lib/small/small/region_asan.c:39:4
    tarantool#3 0x55b5ba4c5d07 in region_aligned_alloc /home/shiny/dev/tarantool-ee/tarantool/src/lib/small/small/region_asan.c:94:14
    tarantool#4 0x55b5b9fb6800 in region_alloc /home/shiny/dev/tarantool-ee/tarantool/src/lib/small/include/small/region_asan.h:131:9
    tarantool#5 0x55b5b9fb6800 in curl_easy_header_cb /home/shiny/dev/tarantool-ee/tarantool/src/httpc.c:124:12
    tarantool#6 0x55b5ba292ab0 in cw_out_ptr_flush /home/shiny/dev/tarantool-ee/tarantool/third_party/curl/lib/cw-out.c:223:16
```

In scope of tarantool/tarantool-ee#1407

NO_DOC=lsan
NO_TEST=lsan
NO_CHANGELOG=lsan

Leak sanitizer started detecting new leaks in etcd-client tests in
the enterprise repo. This only happens on 3.2 branch, and must be
due to the fact we haven't backported commits regarding correct Lua
state cleanup on shutdown. Commit 80a11c4 ("box: close Lua state
on exit") in particular.

Since that patch series is rather heavy, let's simply suppress the leak
in 3.2 branch.

The leaks in question:
```
Direct leak of 52 byte(s) in 1 object(s) allocated from:
   #0 0x556c873b3aae in malloc (/__w/tarantool-ee/tarantool-ee/tarantool/src/tarantool+0x1573aae) (BuildId: b2a73382837eb52617097838e12bd4d33ce21792)
   #1 0x556c89ebd8ec in small_asan_alloc /__w/tarantool-ee/tarantool-ee/tarantool/src/lib/small/small/util.c:94:24
   #2 0x556c89eb5f84 in region_prepare_buf /__w/tarantool-ee/tarantool-ee/tarantool/src/lib/small/small/region_asan.c:39:4
   #3 0x556c89eb6919 in region_aligned_alloc /__w/tarantool-ee/tarantool-ee/tarantool/src/lib/small/small/region_asan.c:94:14
   #4 0x556c8895d4b9 in region_alloc /__w/tarantool-ee/tarantool-ee/tarantool/src/lib/small/include/small/region_asan.h:131:9
   #5 0x556c8894b88a in curl_easy_header_cb /__w/tarantool-ee/tarantool-ee/tarantool/src/httpc.c:124:12
   #6 0x556c89477809 in cw_out_ptr_flush /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/cw-out.c:223:16
   #7 0x556c89477364 in cw_out_do_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/cw-out.c:377:14
   #8 0x556c89476df4 in cw_out_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/cw-out.c:415:14
   #9 0x556c894bab21 in Curl_cwriter_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/sendf.c:183:10
   #10 0x556c894bc525 in cw_download_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/sendf.c:253:14
   #11 0x556c894bab21 in Curl_cwriter_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/sendf.c:183:10
   #12 0x556c8948578e in hds_cw_collect_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/headers.c:367:10
   #13 0x556c894bab21 in Curl_cwriter_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/sendf.c:183:10
   #14 0x556c894bcb6d in cw_raw_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/sendf.c:367:10
   #15 0x556c894bab21 in Curl_cwriter_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/sendf.c:183:10
   #16 0x556c894ba8fe in Curl_client_write /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/sendf.c:91:12
   #17 0x556c89493ab4 in http_write_header /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/http.c:3363:12
   #18 0x556c89492fab in http_on_response /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/http.c:3399:14
   #19 0x556c894909fe in http_rw_hd /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/http.c:3688:14
   #20 0x556c894918b2 in http_parse_headers /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/http.c:3929:14
   #21 0x556c894913f9 in Curl_http_write_resp_hds /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/http.c:3986:14
   #22 0x556c8948a3af in Curl_http_write_resp /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/http.c:4010:12
   #23 0x556c894d6385 in Curl_xfer_write_resp /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/transfer.c:1168:14
   #24 0x556c894d45b4 in sendrecv_dl /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/transfer.c:343:14
   #25 0x556c894d3eb3 in Curl_sendrecv /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/transfer.c:451:14
   #26 0x556c894af0b0 in multi_runsingle /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/multi.c:2374:16
   #27 0x556c894b388a in multi_run_expired /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/multi.c:3151:14
   #28 0x556c894b15d4 in multi_socket /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/multi.c:3234:12
   #29 0x556c894b1701 in curl_multi_socket_action /__w/tarantool-ee/tarantool-ee/tarantool/third_party/curl/lib/multi.c:3358:10

Direct leak of 843 byte(s) in 10 object(s) allocated from:
    #0 0x55b5b99cf745 in malloc (/home/shiny/dev/tarantool-ee/build-asan-release/tarantool/src/tarantool+0x3c7745) (BuildId: 5734aabea48158206be8be71e45f2c40edd09a4b)
    #1 0x55b5ba4c6c9a in small_asan_alloc /home/shiny/dev/tarantool-ee/tarantool/src/lib/small/small/util.c:94:24
    #2 0x55b5ba4c5c42 in region_prepare_buf /home/shiny/dev/tarantool-ee/tarantool/src/lib/small/small/region_asan.c:39:4
    #3 0x55b5ba4c5d07 in region_aligned_alloc /home/shiny/dev/tarantool-ee/tarantool/src/lib/small/small/region_asan.c:94:14
    #4 0x55b5b9fb6800 in region_alloc /home/shiny/dev/tarantool-ee/tarantool/src/lib/small/include/small/region_asan.h:131:9
    #5 0x55b5b9fb6800 in curl_easy_header_cb /home/shiny/dev/tarantool-ee/tarantool/src/httpc.c:124:12
    #6 0x55b5ba292ab0 in cw_out_ptr_flush /home/shiny/dev/tarantool-ee/tarantool/third_party/curl/lib/cw-out.c:223:16
```

In scope of tarantool/tarantool-ee#1407

NO_DOC=lsan
NO_TEST=lsan
NO_CHANGELOG=lsan

fiber_pool_destroy() doesn't destroy the underlying endpoint, neither
does it remove idle fibers from the idle fiber list. This is done by
fiber_pool_shutdown(), but we can't call it from app_thread_f because it
requires a running event loop. If we don't remove the endpoint from
the global list, Tarantool can crash while destroying other endpoints,
for example the applier's endpoint:

```
 tarantool#1  0x593501a3fd1f in crash_collect+256
 tarantool#2  0x593501a4075b in crash_signal_cb+100
 tarantool#3  0x7d8c74045330 in __sigaction+80
 tarantool#4  0x593501a54aed in cbus_endpoint_destroy+337
 tarantool#5  0x5935019010f7 in applier_thread_f(__va_list_tag*)+412
 tarantool#6  0x59350177211c in fiber_cxx_invoke(int (*)(__va_list_tag*), __va_list_tag*)+34
 tarantool#7  0x593501a4beb9 in fiber_loop+219
 tarantool#8  0x593501e29214 in coro_init+118
```

If we don't remove idle fibers from the idle fiber list, Tarantool can
crash while destroying all fibers when the cord is stopped:

```
 tarantool#1  0x5f9fee9486c9 in crash_collect+1945
 tarantool#2  0x5f9fee947e07 in crash_signal_cb+279
 tarantool#3  0x7b0c2e045330 in __sigaction+80
 tarantool#4  0x5f9fee97a242 in fiber_destroy+818
 tarantool#5  0x5f9fee9796b2 in fiber_delete+162
 tarantool#6  0x5f9fee972878 in cord_delete_fibers_in_list+584
 tarantool#7  0x5f9fee9725a4 in fiber_delete_all+84
 tarantool#8  0x5f9fee979bd7 in cord_destroy+903
 tarantool#9  0x5f9fee97ee49 in cord_join+2521
 tarantool#10 0x5f9fedca92b1 in app_threads_stop+81
 tarantool#11 0x5f9fee310fe5 in box_storage_shutdown()+181
 tarantool#12 0x5f9fee310f26 in box_shutdown+150
 tarantool#13 0x5f9fedc98760 in on_shutdown_f(__va_list_tag*)+560
 tarantool#14 0x5f9fedc9649a in fiber_cxx_invoke(int (*)(__va_list_tag*), __va_list_tag*)+26
 tarantool#15 0x5f9fee96f490 in fiber_loop+1056
 tarantool#16 0x5f9fef5ecad4 in coro_init+276
```

Let's destroy the fiber pool directly. This is a quick ugly fix.
We should rework the fiber pool shutdown mechanism in future instead.

Follow-up commit af99552 ("box: introduce application threads").

NO_DOC=unreleased
NO_CHANGELOG=unreleased
NO_TEST=caught by existing tests