Use the standard 'C' locale to handle option conversions correctly in the JNI context. Fixes #13841

[sa-kononov]

RocksDB heavily relies on the default 'C' locale when storing to and reading options from the OPTIONS file.

For example, filter_policy option for bloomfilter has a parameter bits_per_key of double type. When this options is written to the OPTIONS file the value returned by BloomLikeFilterPolicy::GetId() is used. To compose the value, decimal dot is explicitly used:

rocksdb/table/block_based/filter_policy.cc

Lines 1568 to 1584 in d87e598

	std::string BloomLikeFilterPolicy::GetBitsPerKeySuffix() const {
	std::string rv = ":" + std::to_string(millibits_per_key_ / 1000);
	int frac = millibits_per_key_ % 1000;
	if (frac > 0) {
	rv.push_back('.');
	rv.push_back(static_cast<char>('0' + (frac / 100)));
	frac %= 100;
	if (frac > 0) {
	rv.push_back(static_cast<char>('0' + (frac / 10)));
	frac %= 10;
	if (frac > 0) {
	rv.push_back(static_cast<char>('0' + frac));
	}
	}
	}
	return rv;
	}

To read the option parameter the standard C++ std::stod() function is used:

rocksdb/util/string_util.cc

Lines 398 to 404 in d87e598

	double ParseDouble(const std::string& value) {
	#ifndef CYGWIN
	return std::stod(value);
	#else
	return std::strtod(value.c_str(), 0);
	#endif
	}

std::stod() is a locale dependent and for some locales (de_DE.UTF-8, fr_FR.UTF-8, ru_RU.UTF-8, etc) decimal comma is expected and because of this fractional part is not read. Whereas C/C++ code of RocksDB seems to never change the default locale and it's guaranteed to be 'C' by the standard, Java sets locale (for JNI code) according to the system environment.

This bug leads to failures or exceptions in java tests (for example OptionsUtilTest.loadLatestTableFormatOptions) if the said locales are set in the user system.

I suggest to enforce default 'C' locale when JNI library is loaded defining JNI_OnLoad() function from jni.h.

This PR fixes #13841.