V3 pre-merge; all the early bits, for V2

[mgravell]

This is a very large part of #3014, dragged down into v2 - pretty much as much as possible without making the v3 client changes

• bring the eng build tools down, which has FastHash -> AsciiHash
• bring RESPite down, in the current RespReader state from v3
• bring the updated toy server down, entirely migrated to RESPite
• make the minimal client changes to switch to AsciiHash an enum parsing instead of FastHash parsing
• bring down the requests LCS changes and the missing RedisType.VectorSet
• TFM cleanup
• rev minor

Purposes of this PR:

• minimize the size of the V3 PR
• minimize the size of the V2 vs V3 delta going forward
• bring the toy-server down to V2: the V3 core is a lot more stable for the server, and enables MULTI/EXEC (which cannot be easily implemented on the V2 core)

[NickCraver]

I left comments for 3.0 (holy bytes batman), but the more I look at this the more I think we should not backport a change this large with 2.x, and instead just get 3.x previews going. Let's discuss on call and see where y'all are at, just which way I'm leaning after assessing the diff.

[mgravell]

@NickCraver I think I can summarize your feedback into a few buckets:

• #if NET* - yep, simplified; let's do this!
• a few hacky things around the analyzer project
  • tidy how referencing the analyzer works
  • do better about fromBytes
  • use the pre-built indented writer; I'm not sure about this one, seems very messy and low gain for the effort
• a few questions over the key-events API: already considered and implemented as part of the existing shipped design; kicked to Busywork: build-tools; investigate / refactor to use IndentedTextWriter #3033
• some confusion over what APIs we are adding: I suspect I confused you by refactoring the PublicAPI files, but short version: "we're not" - the only API additions are trivial and limited to the LCS/VectorSet ones Philo requested; everything else is just churn noise, so I don't think this is a concern
• a doubt over the size of the FastHash -> AsciiHash migration

Is that fair? I think I've resolved everything except that last AsciiHash one; personally I'm more than comfortable with the FastHash -> AsciiHash, which is actually mostly renaming - I wanted it to be super clear that this has completely undefined behaviour outside of single-octet UTF8 code-points, hence the Ascii. The "big" part is the enum parsing logic, which is basically "take the old logic, and pre-generate a big-ass switch expression in the code-gen, rather than having the consumers write the switch in the consuming code", which makes the consuming code much easier to maintain (and get right); but the logic is unchanged.

[mgravell]

Re "I think we should not backport a change this large with 2.x, and instead just get 3.x previews going." (@NickCraver); for context:

• I need the this PR to get a stable and capable toy-server
• I need a stable and capable toy-server to validate active:active (geo-redundancy) and "smart-client handoffs" (server notifications)
• I need active:active and smart-client handoffs to land in v2, either directly or as backport

The simplest resolution is to land this first.

We can see this toy-server instability in the number of times I've tried to get #3030 green - the v3 server core is rock solid, vs:

[NickCraver]

I'm confused on test status here. We're saying rock solid but still seeing flake - but unclear on ref: rock solid was referring to the V3 branch and not this? I'm just not sure if we need to poke at unexpected failures more here or we're good/no-worse.

Delta looms good 👍 Apologies on delay, fires abound more than usual this week.

[mgravell]

We're saying rock solid but still seeing flake

The specific toy-server tests are solid. This change does nothing to the overall corpus of the tests, because by design it doesn't change the client, and for most of the tests: the server isn't changed positively or negatively.