[r] Port the query-condition logic from TileDB-R to TileDB-SOMA-R

[johnkerl]

Issue and/or context: #3051 [sc-55672]

Changes:

Here I am only introducing a non-exported function parse_query_condition_new, and unit-testing it thoroughly. Replacing the exiting parse_query_condition with this will be a follow-on PR.

Notes for Reviewer:

Timestamp handling will be deferred to a follow-up PR: #3163.

[nguyenv]

nit: I prefer map than if-else for readability.

Suggested change

	tiledb_query_condition_op_t _op_name_to_tdb_op(const std::string& opstr) {
	if (opstr == "LT") {
	return TILEDB_LT;
	} else if (opstr == "LE") {
	return TILEDB_LE;
	} else if (opstr == "GT") {
	return TILEDB_GT;
	} else if (opstr == "GE") {
	return TILEDB_GE;
	} else if (opstr == "EQ") {
	return TILEDB_EQ;
	} else if (opstr == "NE") {
	return TILEDB_NE;
	} else if (opstr == "IN") {
	return TILEDB_IN;
	} else if (opstr == "NOT_IN") {
	return TILEDB_NOT_IN;
	} else {
	Rcpp::stop("Unknown TileDB op string '%s'", opstr.c_str());
	}
	}
	tiledb_query_condition_op_t _op_name_to_tdb_op(const std::string& opstr) {
	static const std::unordered_map<std::string, tiledb_query_condition_op_t> op_map = {
	{"LT", TILEDB_LT},
	{"LE", TILEDB_LE},
	{"GT", TILEDB_GT},
	{"GE", TILEDB_GE},
	{"EQ", TILEDB_EQ},
	{"NE", TILEDB_NE},
	{"IN", TILEDB_IN},
	{"NOT_IN", TILEDB_NOT_IN}
	};
	auto op_pair = op_map.find(opstr);
	if (op_pair != op_map.end()) {
	return op_pair->second;
	} else {
	Rcpp::stop("Unknown TileDB op string '%s'", opstr.c_str());
	}
	}

[nguyenv]

Some other cases I can think of:

• Mismatched types like soma_joinid == "ten"
• What is the behavior for comparing floats and strings like soma_joinid == 10.0?
• What is the behavior for overflow/underflow int8== 100000000?
• Comparing signed and unsigned int8 == -1
• Make sure parens evaluate correctly
• Incomplete query conditions: soma_joinid ==, soma_joinid && int8, soma_joinid == 1 &&

Could potentially do this on a follow-up PR.

[mojaveazure]

LGTM; please bump the develop version, update the changelog, and 🚢

[johnkerl]

@nguyenv re #3162 (comment) I'll do these in a follow-up PR