The testsuite "Datetime string parsing by format (detailed)" tests parsing of a string with various conversion specifications. However, `tostring(dt)` is used as a test oracle, and all these testcases do not test some conversion specifications at all because the metamethod `__tostring` for the datetime object uses `:format()` with the default format string. Due to missed tests for conversion specifications, the behavior described in #10470 was missed: ``` tarantool> dt = date.parse('Mon', {format = '%a'}) tarantool> dt --- - 1970-01-01T00:00:00Z ... tarantool> dt:format('%a') --- - Thu ... ``` The patch adds tests for `strptime` with all possible conversion specifications described in strftime(3) [1][2]. 1. https://man.freebsd.org/cgi/man.cgi?strftime(3) 2. https://pubs.opengroup.org/onlinepubs/009695399/functions/strptime.html Follows up #8588 Follows up #6731 Relates to #10470 NO_CHANGELOG=testing NO_DOC=testing

The patch adds additional assertions for a number of characters parsed by `datetime.parse()`. Follows up #6731 NO_CHANGELOG=codehealth NO_DOC=codehealth

Prior to this patch the count request had been performed in the memtx in a straightforward way: we created an iterator by a type and key and simply called its `next` method until it's exhausted. That means the operation had a linear complexity, which could lead to DoS situations. Also the count operation with ALL iterator hadn't been recorded in the MVCC previously and had an erroneous logic (see the #10140). This is fixed too as a side effect. This patch makes the memtx tree index use a version of BPS tree with the cardinality information enabled and takes advantage of its offset based API to implement the count operation using tree lookups. Since the method does not read each counted tuple now, MVCC subsystem would be unaware of it. In order to fix this, this patch introduces a new entity in the memtx transaction manager to track such operations: GAP_COUNT, and the corresponding `memtx_tx_track_count` function. The entity (gap item) is a record that a concurrent transaction has counted tuples matching some key and iterator type in an index. If a transaction creates such an entity, any insertion or deletion of a matching tuple in the index will be conflicted with it. This works differently for inserts and deletes: 1. If a concurrent transaction inserts a new matching tuple, then its read_gaps list is modified like the counted transaction had read the exact key of the tuple and found nothing. This creates a conflict. 2. If a concurrent transaction deletes a matching tuple, then the transaction that counted the tuple is inserted into the tuple reader list: it pretends to have read the tuple prior to the deletion. This creates a conflict. The existing stories of matching dirty tuples are handled differently. Since its's not stored directly whether the story is a product of an insertion or a replacement, any matching visible tuple is marked as read by the counting transaction and any matching invisible one is marked as gap read, so the conflicting scenarios remain the same for old stories. One thing to be noted is that using the cardinality config introduces a performance regression against the current version of memtx, this is to be mitigated in the scope of #10322. Part of #8204 Closes #10140 NO_DOC=perf improvement NO_CHANGELOG=TBD when fully implemented

The `memtx_tx_index_invisible_count_slow` iterates over stoies of tuples existing in the index in order to count invisible ones. A similar functionality will be required when count gaps will be implemented, so let's refactor this part out of the function and make it macro. Needed for #8204 NO_DOC=refactoring NO_TEST=refactoring NO_CHANGELOG=refactoring

Prior to this patch the `memtx_tx_tuple_clarify_impl` function been used in order to clarify a tuple from index. Similar functionality regarding to top tuple stories will be required when count gaps will be implemented, so let's split the function into two: `memtx_tx_tuple_clarify_impl` and `memtx_tx_story_clarify_impl`, and make the first one call the latter. Needed for #8204 NO_DOC=refactoring NO_TEST=refactoring NO_CHANGELOG=refactoring