RFC Revert "Enable PCRE UTF-8 validity string checks (#26731)"

[KristofferC]

#26731 came with performance regression which severity I think was not fully realized until post merge.

Some examples are:

• The following code went from 0.5 seconds to ~30 minutes https://github.com/JuliaCI/BaseBenchmarks.jl/blob/4362420a20b4e912f9b619819933127976a1097d/src/problem/SpellCheck.jl#L26-L33 (ref Problem suite takes >40 minutes to load JuliaCI/BaseBenchmarks.jl#202).

• Benchmarks vs 0.6 in prep for 0.7 release [do not merge] #27030 (comment):

  julia> f(seq) = search(seq, r">.*\n|\n", 1)
  f (generic function with 1 method)
  
  # 0.6
  julia> @btime f(seq)
  100.660 ns (1 allocation: 32 bytes)
  

  julia> f(seq) = findnext(r">.*\n|\n",seq,1)
  f (generic function with 1 method)
  
  # 0.7
  julia> @btime f(seq)
    60.167 μs (1 allocation: 32 bytes)
  

These regressions are of the type "this used to go instantly" -> "this never finishes in a reasonable time".
Since the PR had possible performance implications that were unknown at the time, I feel the cost/benefit should be considered again.

@nanosoldier runbenchmarks("shootout" || "string" || "problem", vs=":master")

[nanosoldier]

Your benchmark job has completed - no performance regressions were detected. A full report can be found here. cc @ararslan

[StefanKarpinski]

@vtjnash has stated that he's managed to patch PCRE to handle invalid UTF-8 data correctly. If that patch can be resurrected, we should use it. Otherwise, we should document that using regular expressions on invalid UTF-8 data is dangerous and should be avoided.