Lowered most notecard delays, new delays on some errors. (Mantis 3304)

[appurist]

As per the discussion in Mantis 3304:

• GetNumberOfNotecardLines now includes the old 100ms delay on "notecard not found" error cases. (Previously no delay at all, even if errors.)
• If cached, GetNumberOfNotecardLines only delays 25ms now instead of 100.
• If asset fetch required (uncached), GetNumberOfNotecardLines only delays 50ms now instead of 100.
• Notecard line/segment fetches now delay only 1ms (probably 16ms) every 16 lines, starting at the first line, if cached. (Should result in be 1000 lines per second now.)
• Notecard line/segment fetches continue to delay by 25ms if not cached (i.e. first line only), same as above.

[appurist]

I wasn't worried about any "bypass" and in fact the primary goal is to lower the notecard reading times enough that that nobody would ever be encouraged to bypass the load time anyway. Load times are currently incredibly painful, and anyone who wanted to intentionally bypass it could use many other mechanisms, such as just using many scripts to read lines in parallel, etc. There are many attack vectors if one chose to be malicious but we haven't seen a single case of that even with the punishing times. Reducing the load times to 1000 lines per second as above should eliminate any desire to try to circumvent the delays. In fact, they probably would think we've eliminated them.

We discussed eliminating the delays completely, if the notecard was in cache, but I rejected that idea because I was concerned about eliminating a loading penalty in the case of buggy scripts. It doesn't mitigate all buggy script cases though, so if you have a more complex alternative implementation in mind, feed free to implement one. I tried to come up with something that would not require script state to be modified, because it wasn't a priority and the only way this was going to get improved was if it was low-hanging fruit. If you have time for something more, then by all means... ;)