fuzzer is very slow in OT::apply_lookup

[kcc]

the attached input consumes almost 2 minutes to process for the fuzzer (see #139),
making it very inefficient. This is with all the -D flags that restrict the slow paths.
slow-unit-fab39d60d758cb586db5a504f218442cd1395725.pdf

Profile:

 65.17%  harfbuzz_san_co  harfbuzz_san_cov_fuzzer  [.] OT::apply_lookup(OT::hb_apply_context_t*, unsigned int, unsigned int*, unsigned int, OT::LookupRecord const*, unsigned i
 24.96%  harfbuzz_san_co  harfbuzz_san_cov_fuzzer  [.] hb_buffer_t::move_to(unsigned int)                                                                                      
  2.66%  harfbuzz_san_co  harfbuzz_san_cov_fuzzer  [.] OT::PosLookup::apply_recurse_func(OT::hb_apply_context_t*, unsigned int)                                                
  1.48%  harfbuzz_san_co  harfbuzz_san_cov_fuzzer  [.] OT::match_input(OT::hb_apply_context_t*, unsigned int, OT::IntType<unsigned short, 2u> const*, bool (*)(unsigned int, OT
  1.16%  harfbuzz_san_co  harfbuzz_san_cov_fuzzer  [.] OT::RuleSet::apply(OT::hb_apply_context_t*, OT::ContextApplyLookupContext&) const                                       
  1.03%  harfbuzz_san_co  harfbuzz_san_cov_fuzzer  [.] OT::hb_apply_context_t::skipping_iterator_t::next()  

BTW, Ideally, I still think we should be fuzzing the same setting as used for production (i.e. no separate build)

[behdad]

Sure, we limited the recursion depth, so fuzzer found a font that recurses to the same lookup 280 times... Anyway, put a workaround in, but as we discussed...

[kcc]

The fuzzer is running at > 5000 exec/s once again! Woo-hoo!
(not sure for how long :)

[behdad]

Fingers crossed...