Due to inconsistency of Tarantool type casting while using strict
data types as "double" or "unsigned" it is needed
to use "number" data type in a whole bunch of cases.
However "number" may contain "decimal" that will be serialized into
string by JSON builtin module.

This commit adds "encode_decimal_as_number" parameter to json.cfg{}.
That forces to encode `decimal` as JSON number to force type
consistency in JSON output.
Use with catious - most of JSON parsers assume that number is restricted
to float64.

NO_DOC=we do not host doc

Nikolay Shirokovskiy authored 2 years ago and Дмитрий Кольцов committed 2 years ago

As it breaks sane usage of region as a data stack:

	size_t region_svp = region_used(&fiber()->gc);
	/* some allocation on fiber gc and usage of allocated memory. */
	region_truncate(&fiber()->gc, region_svp);

If in the above snippet one calls a function that in turn calls
`fiber_gc` then the snippet code may have use-after-free and later UB
on truncation.

For this reason let's get read of fiber_gc. However we need to make sure
we won't introduce leaks this way. So before actually removing
fiber_gc we make it perform leak check instead and only after fixing
all the leaks the fiber_gc was removed.

In order to find the leak easily the backtrace of the first fiber gc
allocation that is not truncated is saved and then reported.

In order to catch leaks that are not triggered by the current test suit
and to prevent introducing leaks in future patches the leak check is
added on fiber exit/recycle and for long living system fibers on every loop
iteration.

Leak check in release build is on but without leak backtrace info by
default for performance reasons. Backtrace can be provided by using
`fiber.leak_backtrace_enable()` knob before starting leaking fiber.

Regularly leaks are only reported in log but it will not help to
catch errors when running test suits so build option ABORT_ON_LEAK
is added. When it is on we abort on leak. This option is turned off
for all builds that used in CI.

Closes #5665

NO_CHANGELOG=internal
NO_DOC=internal

The YAML serializer fails to detect aliases in objects returned by
the __serialize method:

tarantool> x = {}
---
...

tarantool> {a = x, b = x}
---
- a: &0 []
  b: *0
...

tarantool> setmetatable({}, {
         >     __serialize = function() return {a = x, b = x} end,
         > })
---
- a: []
  b: []
...

Fix this by scanning the object returned by the __serialize method
(called by luaL_checkfield) for references.

Closes #8240

NO_DOC=bug fix

(cherry picked from commit b42302f5)

lbox_push_event_f and lbox_push_event_f callback functions used for
passing the statement between txn and space on/before replace Lua
triggers don't assume that the transaction may be aborted by yield
after the current statement began (this may happen if a trigger callback
yields). In this case, all statements in txn would be rolled back and
txn_current_stmt would return NULL, leading to a crash.

Let's fix this by checking if the transaction is still active and
raising an error immediately if it isn't, thus skipping Lua triggers.

Notes:
 - We merged lbox_pop_txn_stmt_and_check_format into lbox_pop_txn_stmt,
   because the latter is only called by the former.
 - Since lbox_push_event_f callback may now fail, we have to update
   lbox_trigger_run to handle it.

Closes #8027

NO_DOC=bug fix

(cherry picked from commit 1a678a5e)

Before the patch, fiber->storage.lua.stack is used for
`panic` calls. However, some fibers don't have any Lua
state saved in their storage (for example, space
triggers).

After the patch, the Lua state pointed by `cur_L` is
used to make those calls, as it is always present.

Closes #6647
NO_DOC=bugfix

(cherry picked from commit dfe79b9a)

1. Fixed modification of a variable passed to the logging function
   (both log formats)

   tarantool> a = {foo = 'bar', file = 'c://autorun.bat'}
   tarantool> log.info(a)
   [...]
   tarantool> a
   (before) - foo: bar
    (after) - foo: bar
              file: c://autorun.bat

2. Fixed the drop of fields with reserved internal names (plain log format)

   tarantool> log.info({foo = 'bar', pid = 666})
   (before) {"foo":"bar"}
    (after) {"foo":"bar","pid":666}

3. Now if 'message' field is absent, it is set to the first field of the
   table (JSON log format)

   tarantool> log.info({'Hello, world', key = 'value'})
   (before) {[...], "1":"Hello, world", "key":"value", [...]}
    (after) {[...], "message":"Hello, world", "key":"value", [...]}

4. Fixed assertion on a table without string keys (JSON log format)

   If a Lua table, passed to say(), contains only integer indexes,
   json.encode() will encode it as an array rather than a map, thereafter
   say_format_json() will produce improperly formatted JSON string, or get
   assertion failure. Fix it by encoding all kinds of tables as maps.

Closes #3853
Closes #7955

NO_DOC=Mostly bug fixes, the format of the JSON log is not documented.

(cherry picked from commit 85ef1118)

fh:pread() will raise a clear error on wrong arguments.

Closes #4963

NO_DOC=bugfix
NO_CHANGELOG=bugfix

(cherry picked from commit 22ecf87a)

Drop unused code and arguments to fix the warning:

src/lua/log.lua:223:11: variable log_type is never accessed

Follow-up commit 21c6fa6e ("say: enable json log format with
syslog").

NO_DOC=luacheck
NO_TEST=luacheck
NO_CHANGELOG=luacheck

All the heavy lifting was done in the previous commit that dropped
the syslog formatter. This commit just removes the checks that forbid
using syslog with json.

Closes #7860

@TarantoolBot document
Title: JSON log format can now be used with syslog

The configuration reference says that syslog is incompatible with
the JSON log format:

https://www.tarantool.io/en/doc/latest/reference/configuration/#confval-log_format

This isn't true anymore. If JSON is used with syslog, then a JSON
message body is appended to the syslog header.

See https://github.com/tarantool/tarantool/issues/7860.

(cherry picked from commit ec1747b4)

Closes #7797

NO_DOC=security fix
NO_TEST=security fix

(cherry picked from commit dd7d46af)

getenv() return values cannot be trusted, because an attacker might set
them. For instance, we shouldn't expect, that getenv() returns a value
of some sane size.

Another problem is that getenv() returns a pointer to one of
`char **environ` members, which might change upon next setenv().

Introduce a wrapper, getenv_safe(), which returns the value only when
it fits in a buffer of a specified size, and copies the value onto the
buffer. Use this wrapper everywhere in our code.

Below's a slightly decorated output of `grep -rwn getenv ./src --include
*.c --include *.h --include *.cc --include *.cpp --include *.hpp
--exclude *.lua.c` as of 2022-10-14.
`-` marks invalid occurences (comments, for example),
`*` marks the places that are already guarded before this patch,
`X` mars the places guarded in this patch, and
`^` marks places fixed in the next commit:

NO_WRAP
```
* ./src/lib/core/coio_file.c:509:	const char *tmpdir = getenv("TMPDIR");
X ./src/lib/core/errinj.c:75: const char *env_value = getenv(inj->name);
- ./src/proc_title.c:202: * that might try to hang onto a getenv() result.)
- ./src/proc_title.c:241:	* is mandatory to flush internal libc caches on getenv/setenv
X ./src/systemd.c:54: sd_unix_path = getenv("NOTIFY_SOCKET");
* ./src/box/module_cache.c:300: const char *tmpdir = getenv("TMPDIR");
X ./src/box/sql/os_unix.c:1441: azDirs[0] = getenv("SQL_TMPDIR");
X ./src/box/sql/os_unix.c:1446: azDirs[1] = getenv("TMPDIR");
* ./src/box/lua/console.c:394: const char *envvar = getenv("TT_CONSOLE_HIDE_SHOW_PROMPT");
^ ./src/box/lua/console.lua:771: local home_dir = os.getenv('HOME')
^ ./src/box/lua/load_cfg.lua:1007: local raw_value = os.getenv(env_var_name)
X ./src/lua/init.c:575: const char *path = getenv(envname);
X ./src/lua/init.c:592: const char *home = getenv("HOME");
* ./src/find_path.c:77: snprintf(buf, sizeof(buf) - 1, "%s", getenv("_"));
```
NO_WRAP

Part-of #7797

NO_DOC=security

(cherry picked from commit b86395ff)

dt.new() will raise a clear error on wrong timestamp type.

Closes #7273

NO_DOC=bugfix
NO_CHANGELOG=bugfix

(cherry picked from commit 8d4cbf44)

strerror() is MT-Unsafe, because it uses a static buffer under the hood.
We should use strerror_r() instead, which takes a user-provided buffer.
The problem is there are two implementations of strerror_r(): XSI and
GNU. The first one returns an error code and always writes the message
to the beginning of the buffer while the second one returns a pointer to
a location within the buffer where the message starts. Let's introduce a
macro HAVE_STRERROR_R_GNU set if the GNU version is available and define
tt_strerror() which writes the message to the static buffer, like
tt_cstr() or tt_sprintf().

Note, we have to export tt_strerror(), because it is used by Lua via
FFI. We also need to make it available in the module API header, because
the say_syserror() macro uses strerror() directly. In order to avoid
adding tt_strerror() to the module API, we introduce an internal helper
function _say_strerror(), which calls tt_strerror().

NO_DOC=bug fix
NO_TEST=code is covered by existing tests

(cherry picked from commit 44f46dc8)

In brief: `vfork()` on Mac OS 12 and newer doesn't suspend the parent
process, so we should wait for `setpgrp()` to use `killpg()`. See more
detailed description of the problem in a comment of the
`popen_wait_group_leadership()` function.

The solution is to spin in a loop and check child's process group. It
looks as the most simple and direct solution. Other possible solutions
requires to estimate cons and pros of using extra file descriptor or
assigning a signal number for the child -> parent communication.

There are the following alternatives and variations:

* Create a pipe and notify the parent from the child about the
  `setpgrp()` call.

  It costs extra file descriptor, so I decided to don't do that.
  However if we'll need some channel to deliver information from the
  child to the parent for another task, it'll worth to reimplement this
  function too.

  One possible place, where we may need such channel is delivery of
  child's errors to the parent. Now the child writes them directly to
  logger's fd and it requires some tricky code to keep and close the
  descriptor at right points. Also it doesn't allow to catch those
  errors in the parent, but we may need it for #4925.
* Notify the parent about `setpgrp()` using a signal.

  It seems too greedly to assign a specific signal for such local
  problem. It is also unclear how to guarantee that it'll not break any
  user's code: a user can load a dynamic library, which uses some
  signals on its own.

  However we can consider using this approach here if we'll design some
  common interprocess notification system.
* We can use the fiber cond or the `popen_wait_timeout()` function from
  PR #7648 to react to the child termination instantly.

  It would complicate the code and anyway wouldn't allow to react
  instantly on `setpgrp()` in the child.

  Also it assumes yielding during the wait (see below).
* Wait until `setpgrp()` in `popen_send_signal()` instead of
  `popen_new()`.

  It would add yielding/waiting inside `popen_send_signal()` and likely
  will extend a set of its possible exit situations. It is undesirable:
  this function should have simple and predictable behavior.
* Finally, we considered yielding in `popen_wait_group_leadership()`
  instead of sleeping the whole tx thread.

  `<popen handle>:new()` doesn't yield at the moment and a user's code
  may lean on this fact.

  Yielding would allow to achieve better throughtput (amount of parallel
  requests per second), but we don't take much care to performance on
  Mac OS. The primary goal for this platform is to offer the same
  behavior as on Linux to allow development of applications.

I didn't replace `vfork()` with `fork()` on Mac OS, because `vfork()`
works and I don't know consequences of calling `pthread_atfork()`
handlers in a child created by popen. See the comment in `popen_new()`
near to `vfork()` call: it warns about possible mutex double locks. This
topic will be investigated further in #6674.

Fixes #7658

NO_DOC=fixes incorrect behavior, no need to document the bug
NO_TEST=already tested by app-tap/popen.test.lua

(cherry picked from commit e2207fdc)

Currently this script causes 100% CPU usage for 10 sec, because
os.exit() infinitely yields to the scheduler until on_shutdown
fiber completes and breaks the event loop. Fix this by a sleep.

```
box.ctl.set_on_shutdown_timeout(100)
box.ctl.on_shutdown(function() require('fiber').sleep(10) end)
os.exit()
```

Closes #6801

NO_DOC=bugfix
NO_TEST=don't know how to catch this by a test

Co-authored-by: Georgy Moshkin <louielouie314@gmail.com>
(cherry picked from commit 6d91e44b)

There are a number of internal system fibers which are not supposed to
be cancelled.

Let's introduce `FIBER_IS_SYSTEM` flag that will indicate, if the fiber
can be explicitly killed. If this flag is set, killing functions will
just ignore cancellation request.

This commit introduce blocking system fiber cancelling only from the Lua
public API, as it is more important to have it right. The prohibition to
cancel fibers from C API will be introduced later.

Related to #7448
Part of #7473

NO_DOC=internal
NO_TEST=will be added in subsequent commit
NO_CHANGELOG=internal

(cherry picked from commit 3a18a9bf)

struct trigger is about to get a new field, and it's mandatory that this
field is specified in all initializers. Let's introduce a macro to avoid
adding every new field to all the initializers and at the same time keep
the benefits of static initialization.

Also while we're at it fix `lbox_trigger_reset` setting all trigger
fileds manually.

Part-of #4264

NO_DOC=refactoring
NO_CHANGELOG=refactoring
NO_TEST=refactoring

(cherry picked from commit 2040d1f9)

If two or more fibers are yielding in fiber_join_timeout(), one of them
will eventually join and recycle the fiber, while the rest will crash
on accessing the recycled fiber's struct. Fix this by doing fiber_find()
again after each waiting attempt in lbox_fiber_join().

Closes #7489
Closes #7531

NO_DOC=bugfix

(cherry picked from commit 8f4538cb)

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

Part of #7228

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

The following functions are added into the module API:

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

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

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

(cherry picked from commit c75fbce1)

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

Part of #7228

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

(cherry picked from commit 225a6213)

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

Part of #7228

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

(cherry picked from commit 1eadf531)

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

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

Part of #7228

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

(cherry picked from commit 21f6a4b7)

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

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

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

A couple of notes around the change:

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

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

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

Part of #7228

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

(cherry picked from commit b4f6675a)

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

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

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

Part of #7228

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

(cherry picked from commit 450e2664)

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

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

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

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

Part of #7228

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

(cherry picked from commit 3061bea9)

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

Part of #7228

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

(cherry picked from commit 62906a9c)

We did not retain correctly `hour` attribute if modified
via `:set` method attributes `min`, `sec` or `nsec`.

```
tarantool> a = dt.parse '2022-05-05T00:00:00'

tarantool> a:set{min = 0, sec = 0, nsec = 0}
--
- 2022-05-05T12:00:00Z
...
```

Closes #7298

NO_DOC=bugfix

(cherry picked from commit ba140128)

Two things we need to do to fix build with OpenSSL 3.0:

1. Use EVP_MAC_* functions instead of HMAC_*
   https://www.openssl.org/docs/man3.0/man3/HMAC_CTX_new.html

2. Load the Legacy provider to enable legacy algorithms, such as MD4
   https://wiki.openssl.org/index.php/OpenSSL_3.0#Programming_in_OpenSSL_3.0

Closes #6477

NO_DOC=build fix
NO_TEST=build fix
NO_CHANGELOG=build fix

(cherry picked from commit e3bf73c8)

openssl_err_str is used for reporting OpenSSL errors. It calls
crypto_ERR_* functions using FFI. There's a typo in the code:
ffi.crypto_ERR_error_string is used instead of ffi.C.*.

We don't normally step on this, because OpenSSL doesn't return errors
in our configuration, but if it did for some reason (e.g. a cipher was
disabled in the library), we'd get a confusing error message.

NO_DOC=bug fix
NO_TEST=occur only on internal error
NO_CHANGELOG=occur only on internal error

(cherry picked from commit f72662c5)

Commit b18dd47f ("Introduce backtrace=true option to fiber.info()")
introduced a way to skip backtraces in fiber.info() calls.
Commit 9da7e03e ("fiber: introduce fiber_o:info() and fiber_o:csw()")
introduced `options` function for fiber object however it ignored
passed options.
This patch fixed it. Currently fiber:info({backtrace = false})
returns info without backtrace.

Closes #7210

NO_DOC=bugfix

(cherry picked from commit 0eac13b9)

We used to not implement comparison operators for interval
objects, thus any compare (even of equal) objects returned false:

	```
	tarantool> dt1 = datetime.new()
	---
	...

	tarantool> dt2 = datetime.now()
	---
	...

	tarantool> dt1 - dt1 == dt2 - dt2
	---
	- false
	...
	```

Now we implemented comparison for interval objects, where we compare
field by field starting from highest attribute (e.g. `year`) to
smallest attribute (e.g. `nsec`) and if any of comparison
returned non zero value then we return this result.

NO_DOC=bugfix
NO_CHANGELOG=bugfix

(cherry picked from commit 65a3c17f)

Fixed incorrect interval initialization for case of `()` used
while it was correct for `{}` arguments.

NO_DOC=bugfix
NO_CHANGELOG=bugfix
NO_TEST=bugfix

```
tarantool> itv = require('datetime').interval.new{}
---
...

tarantool> itv
---
- 0 seconds
...

tarantool> itv = require('datetime').interval.new()
---
...

tarantool> itv
---
- +0.000000001 seconds
...
```

(cherry picked from commit d183ae6d)

Extended gen-zone-abbrevs.pl script with capability to generate
timezones.lua in addition to timezones.h.

That's bidirectional Lua translation table for resolution of
timezone name by it's index and vice versa. Exported to Lua
world via `datetime.TZ`

NO_DOC=next commit

(cherry picked from commit 9ee45289)

Properly calculate `isdst` field in datetime Lua object and
for attribute returned by `:totable()` function.

NO_DOC=next commit

(cherry picked from commit aec6fbac)

* Modified localtime.c to use tnt_tm instead of tm structure;
* Use this structure for passing data to tnt_localtime_rz at
  the moment of time-zone resolution;
* As a side-effect of refactoring - simplified singleton we
  used to use for automagical sorting of array with timezone
  abbreviations

NO_DOC=internal
NO_CHANGELOG=internal

(cherry picked from commit 2116bbfd)

LuaJIT submodule is bumped to introduce the following changes:
* sysprof: change C configuration API
* sysprof: enrich symtab on a new trace or a proto
* sysprof: fix SYSPROF_HANDLER_STACK_DEPTH
* sysprof: make internal API functions static
* sysprof: add LUAJIT_DISABLE_SYSPROF to Makefile
* symtab: check the _GNU_SOURCE definition

Within this changeset Tarantool-specific backtrace handler is introduced
and set to be used by sysprof machinery.

Besides, all new public Lua C API introduced within this changeset is
added to extra/exports.

Follows up #781

NO_DOC=LuaJIT submodule bump
NO_TEST=LuaJIT submodule bump
NO_CHANGELOG=LuaJIT submodule bump

(cherry picked from commit f40ad50d)

Consider the following case a safe `select` call (i.e., do not issue a
warning):
* offset + limit <= 1000 (default value of offset is 0, default value of
limit is 4294967295);

Add new dangerous `select` call case:
* 'ALL', 'GE', 'GT', 'LE', 'LT' iterator even with key present.

Because of the additional logic, it was decided to refactor
`check_select_args` and call it after resolving options in
`check_select_opts`.

Closes #7129

@TarantoolBot document
Title: improve check for dangerous `select` calls

Calls with `offset + limit <= 100`
are now considered safe (i.e., a warning is not issued), e.g.:
box.space.s:select(nil, {offset = 1000})
box.space.s:select(nil, {limit = 1000})
box.space.s:select(nil, {offset = 500, limit = 500})

'ALL', 'GE', 'GT', 'LE', 'LT' iterators are now considered dangerous by
default even with key present, e.g.:
box.space.s:select({0})
box.space.s:select({0}, {iterator = 'GE'})

But not that these calls are still safe:
box.space.s:select({0}, {limit = 1000})
box.space.s:select({0}, {limit = 1000, iterator = 'GE'})
box.space.s:select({0}, {iterator = 'EQ'})

(cherry picked from commit 29654ffe)

Constructor date.new() and modifier date:set() should always produce same
result for all attributes combinations. Fixed the problem for
`timestamp` with `tzoffset`.

Fixes #6793

@TarantoolBot document
Title: datetime :set{} with tzoffset

Constructor `date.new()` and modifier `date:set()` should always produce
same result for all attributes combinations. Fixed the problem for
`timestamp` with `tzoffset`.

```
tarantool> date.new{tzoffset = '+0800', timestamp = 1630359071}
---
- 2021-08-30T21:31:11+0800
...

tarantool> date.new():set{tzoffset = '+0800', timestamp = 1630359071}
---
- 2021-08-30T21:31:11+0800
...
```

(cherry picked from commit d56840d7)

Since recently we partially support timezone names (i.e. as
abbreviations) so we may modify tz attribute support for
datetime constructors or :set() operations.

Closes #7076
Relates to #7007

@TarantoolBot document
Title: datetime tz attribute

Now `tz` attribute is properly handled in datetime value
constructors or `:set{}` method modifiers.

```
tarantool> T = date.new{year = 1980, tz = 'MSK'}
---
...

tarantool> T.tzoffset
---
- 180
...

tarantool> T.tz
---
- MSK
...
tarantool> T = date.new{year = 1980, tzoffset = 180}
---
...

tarantool> T.tzindex
---
- 0
...

tarantool> T.tz
---
-
...

tarantool> T.tzoffset
---
- 180
...

tarantool> T:set{tz = 'MSK'}
---
...

tarantool> T.tz
---
- MSK
...

```

(cherry picked from commit 7036b55a)

ffi.typeof() returns cdata, which in turn can't be concatenated with string
without explicit call of `tostring`. Moreover, passing data of native Lua
type would also generate wrong error. So let's simply raise general error
without mentioning passed type.

NO_DOC=<Internal fix>
NO_CHANGELOG=<Internal fix>

(cherry picked from commit f715e36a)