Verify that {first = <...>} in select/pairs does not fall into full scan, when it does not

[Totktonada]

See https://github.com/tarantool/crud/pull/169/files#r652086030 and #158 (comment)

[Totktonada]

@oleg-jukovec Please, take a look when time will permit.

[oleg-jukovec]

1. In the Select: jsonpath indexes #158 was suggested to delete the logic of choosing bigger value from scan value and after. That would be a mistake because even in the simple example:

crud.select('space', {}, {after = value})

will be a fullscan (we will scroll from beginning of the index to after, otherwise we start from after).

We have such logic in the master branch:

crud/crud/select/executor.lua

Lines 44 to 69 in aea0977

	if has_keydef then
	generate_value = function(after_tuple, scan_value, index_parts, tarantool_iter)
	local key_def = keydef_lib.new(index_parts)
	if #scan_value == 0 and after_tuple ~= nil then
	return key_def:extract_key(after_tuple)
	end
	local cmp_operator = select_comparators.get_cmp_operator(tarantool_iter)
	local cmp = key_def:compare_with_key(after_tuple, scan_value)
	if (cmp_operator == '<' and cmp < 0) or (cmp_operator == '>' and cmp > 0) then
	return key_def:extract_key(after_tuple)
	end
	end
	else
	generate_value = function(after_tuple, scan_value, index_parts, tarantool_iter)
	local after_tuple_key = utils.extract_key(after_tuple, index_parts)
	if #scan_value == 0 and after_tuple ~= nil then
	return after_tuple_key
	end
	local cmp_operator = select_comparators.get_cmp_operator(tarantool_iter)
	local scan_comparator = select_comparators.gen_tuples_comparator(cmp_operator, index_parts)
	if scan_comparator(after_tuple_key, scan_value) then
	return after_tuple_key
	end
	end
	end

It works as expected.

2. WIP: Multipart index single field query #169 adds some new tests that does not work as expected.

We have this tests in the master branch (and some more tests which was broken by #177 ):

crud/test/integration/select_test.lua

Lines 1186 to 1187 in aea0977

	local result, err = g.cluster.main_server.net_box:call('crud.select', {'coord', conditions,
	{after = result_0.rows[1]}})

It works fine too.

I rechecked the current implementation of choosing from scan value and after + scrolling to after. It works as expected (at least with examples related to the issue).

It seems to me the issue is outdated. I close it.