HSEARCH-1315 Replacing Point class reference with Coordinates interface on api level
HSEARCH-1315 Introduce a Point.fromCoordinates(Coordinates) helper
HSEARCH-1315 Hide Point from all public APIs (and simplify code)
HSEARCH-1315 DistanceSortField is public API for Sort operations on distances
Fix line endings
HSEARCH-1309 Removing .gitignore in integration module and updating project wide .gitignore from project root. Removing irrelevant settings.
HSEARCH-1309 moving everything into as sub module
HSEARCH-1309 Making sure the h2 test directory is created in target
HSEARCH-1309 Splitting as module into as, spring and performance. Cleaning up dependencies.
HSEARCH-1309 Making sure that the current test class is passed to getIndexDir. If TestConstant gets used as a test dependency it won't be in the classes directory, but a jar dependency
.gitignore should contain /bin as well
HSEARCH-1307 Performance tests should not run with debug logging enabled
HSEARCH-1307 Introduce a validating performance and stress test for the NRT backend
HSEARCH-1307 NRT backend could hit AlreadyClosedException: this IndexReader is closed
HSEARCH-1307 Fixing a typo, renaming some constants
HSEARCH-1307 Style fixes
HSEARCH-1329 The two variants of ReaderPerformanceTestCase are failing
HSEARCH-1330 Making sure the actual test class (the one extending SearchTestCase) is passed to TestConstants#getIndexDirectory
HSEARCH-1317 Optimize tail recursion in NRT IndexReader reopening
HSEARCH-1317 Boosting performance: removing contention between writers and readers

Visibility of changes are guaranteed by the volatile flush mentioned in the code comments; now on to why the writes on these different state flags and counters is ok to not be fully atomic.
Initially I considered moving all state in a little valueobject to be replaced atomically, but this:
 - is more complex to replace than a simple CAS operation as there are counter increments involved
 - this level of consistency is not needed

Considering there is commonly [1] just one thread invoking this, this is basically a CAS operation with a value object.

Why is this level of consistency not needed?
* On counters: they grow monotonically and all what the readers care is to not see a value which flags their state as "outdated"
* On in-flight flags: worst case some state (either deletes or writes) is flushed which wasn't strictly required to be flushed yet - but still this is welcome as this state would need to be flushed very soon: it will be a requirement at the next refresh operation, so in practice if we're ready to include those changes as well in the same IO operation now, it's better to do it all in one go as the worst case scenario (the race condition) is beneficial for performance as it allows us to skip some IO.

Note that this is tested by the existing test org.hibernate.search.test.performance.nrt.ReadWriteParallelismTest: it effectively isolates this component to put a lot of contention on this structure, and does validation of correct state being visible.

[1] Only whan a MassIndexer is running we might have parallel invocations of the setupNewReadersRequirements() method.