Remove legacy range-index (NativeValueIndex)

[adamretter]

I found some detail/discussion that I started about doing this previously: http://exist.markmail.org/thread/uymso4dl6idflmwc#query:+page:1+mid:uymso4dl6idflmwc+state:results

@wolfgangmm It would be good if you could give me any follow-up on that thread, i.e. if you have any strong thoughts on how to deal with fn:matches.

[wolfgangmm]

There are still some functions which could not be ported to the new range index yet, including ft:matches, ft:id and ft:idref. Moving the id functions into Lucene shouldn't be difficult; fn:matches may be trickiest due to the limited support for regular expressions in Lucene.

[adamretter]

It looks to me like org.exist.storage.StorageAddress encodes the type of the value for a node as indexed by the Legacy Range Index and stores that into the dom.dbx. Presumably if the legacy range index was removed we could also remove this now unnecessary storage. @wolfgangmm can you confirm?

[adamretter]

Will also lead to the removal of DBBroker#endElement and NativeBroker#endElement

[adamretter]

It seems that we have two options with Lucene and regular expressions:

1. We use the older RegexQuery class and call setRegexImplementation(new JavaUtilRegexCapabilities()).
2. We attempt to compile the XPath regular expression language down into multiple Regexp automata e.g. using the newer RegexpQuery. e.g. https://gist.github.com/mumrah/6104234

The javadoc for (1) warns that it is not as fast as (2) but it does have full Java regular expression support. A look at the Lucene code shows that it does an index scan calling matches on a java.util.pattern.Matcher, as this is pretty much what the org.exist.storage.RegexMatcher already does in eXist, I am hopeful we can avoid a performance drop.

I will attempt (1) as it seems like the simplest approach.