(cherry picked from commit 7e9f7d2a276a13a4aa3d39492b12090303711131)
(cherry picked from commit ed6d7ef139fd98b4601dee45775bcf25cd03925f)

There was a problem when working with stores of different format. If you had record format configured in your neo4j.conf, the copy would refuse to read from some databases. This setting is now ignored in the copy command.

After version bump of jetty, SslContextFactory.Server needs to be used instead of SslContextFactory.

The copy command can be used to clean up inconsistencies, compact stores, and do an upgrade at the same time. Also, we can allow a bigger range of upgrades, e.g. 3.4 directly to 4.1, skipping the intermediate steps of 3.5.latest -> 4.0.latest -> 4.1. Those steps are needed to migrate the schema, but since we don't copy the schema store at all during a copy, they are not needed. The schema will have to be re-created in the end on the copied to database.

This is solely for testing and will allow tests to produce
records that required secondary units at much lower data sizes.

Where calling next() would always go to the next page.
This breaks the typical interaction contract with a PageCursor
where it's expected that the first call to next() places it
on the page it was instantiated to start on.

The place which discovered this was BaseHighLimitRecordFormat
where it would set up a composite page cursor. The secondary
cursor would be opened as a linked cursor placed at the calculated
page and offset and when a call to next() would be made
right after instantiation it would instead go to the next page
and write there, which is wrong.

When providing input files to the importer, e.g. nodes and
you wanted to have a complex regex pattern like:

--nodes=myheader.csv,myfile_\d{1,5}

Comma being the separator between files/patterns there was a problem
where the second comma found inside the regex pattern would be
interpreted as a delimiter and so the command would split that
string into:

- myheader.csv
- myfile_\d{1
- 5}

And would therefore not find the expected files. To accommodate for
this the provided patterns now have support for quotes, like so:

--nodes=myheader.csv,'myfile_\d{1,5}'

which will prevent the comma inside the quotation to be interpreted
as a delimiter.

This commit also fixes another issue with regex patterns on Windows
where backslash characters are naturally part of files names
and so distinguishing between the two cases requires some
additional care which has been added to the parsing of these strings.

A couple of higher-order bits of the long values when using INTEGER
id type in the importer are reserved for internal use, but the
LongEncoder didn't check that the incoming ID values were not using
any of those bits. This would instead produce unexpected ordering
failures later on in the sorting process.

Seems like the 5s timeout was too short on the old windows machines on TC

Jetty 9.4.17 -> 9.4.34 - https://nvd.nist.gov/vuln/detail/CVE-2020-27216
Jersey 2.29 -> 2.32 - SRCCLR-SID-3606
Jackson 2.10.0 -> 2.10.5 - For version compatibility

There were two issues, both triggered with the same added test:

- LeafReader#getLiveDocs() can rightfully return null, meaning
  that the leaf has no deletions.
- Comparison with maxDoc was off-by-one since reader.maxDoc()
  returns one greater than max (i.e. high ID).

It disappeared in the migration to PicoCLI. Will add this
footer to the usage printing:

Environment variables:
  NEO4J_CONF    Path to directory which contains neo4j.conf.
  NEO4J_DEBUG   Set to anything to enable debug output.
  NEO4J_HOME    Neo4j home directory.
  HEAP_SIZE     Set JVM maximum heap size during command execution...

Page cursor had a weakness when doing a page fault, such that
very specific errors would cause the acquired latch to
never be released. This would in turn create a trap for all later
cursors who wanted to page fault that page such that they would get
stuck forever. Sooner or later all threads could end up stuck
in this trap. The specific interaction triggering this
initially was a concurrent closing of the cursor while it was
page faulting, alternatively while there was a failure doing
the page faulting.

Even tho the concurrent closing of the cursor while page faulting
very likely is "forbidden", unexpected and would point to some
error regarding handling and life cycle of page cursors in transactions,
tightening up this weakness is still a good idea.
Investigating why this interaction occurs at all will be a separate
thing and unrelated to this change.

IndexingService would remember dropped index IDs during recovery
and instead drop them after recovery was completed. Main reason
for that was that the index statistics were previously in the
counts store and that store couldn't be updated during recovery
without throwing exception. That deferred map would cause a problem
in the scenario where an index with ID X would be dropped and
then later on during the same recovery another index with the
same ID X would be created. Then the index would be removed
from the "indexes to drop later" map without closing or dropping it
and then later closing the page cache would notice an unclosed
paged file and would fail recovery.

This deferred drop of indexes is no longer required altogether
and so this problem can now go away. Also tightened up some
checks regarding overwriting any existing ID in the IndexMap.

The consistency checker uses IndexAccessor#newAllEntriesReader()
method to read all entity IDs from that index. In Lucene the
all-documents-reader had a flaw where it would always fail if reading
from a Lucene index or partition that had deletions which hadn't
been merged yet. The reader would try to remove from an unmodifiable
list. Now it uses an iterator instead.

Before we could accidentally take action on a failed read before checking 'shouldRetry'.
This meant, in some tests, we could end up trying to create an array of negative size.
In production this is not a problem (up until at least 4.2) because we don't have any
indexes that offload store and also store data in the values.
(Only BTREE indexes use offload store)

The purpose of this change is to guarantee configured IOPS limits.

Before this change, the page cache could flush more aggressively
than the IOPS limit depending on layout of dirty pages.
The reason was that it processed 4k page segments before invoking
the IO limiter which would block only for up to 100ms.
This could lead to pages being flushed at rate up to 40k/s,
depending on the distribution of dirty pages
among the 4k page segments.

We don’t use java-modules, so all modules are undefined. Therefor the search is broken. To fix this, we can explicitly state the use of module directories to false, so that the JavaScript based search won’t lead to classes being in an `UNDEFINED` directory.

Related fix in the Java Driver repo https://github.com/neo4j/neo4j-java-driver/commit/d7c1c1c87d9bba5ceaa9c7a6bcfe9206f225bb41.

In planning whenever we encountered an eventually consistent
index we throw an error when trying to map the behaviour to a scala
equivalent.

changelog: Fix error where we could get an error Missing kernel to cypher mapping for index behaviour: EVENTUALLY_CONSISTENT in Cypher.

This is because the original is based on some assumptions about transaction logs, which are not necessarily accurate.

This fixes a bug where we were actually sending the full-size in the dump-size field.

There are some dependencies between the user log settings that aren't obvious - now documented.

Fix a bug in PIPELINE runtime with fusing when evaluating AND/OR expressions.