follow up on ways to reduce allocation on multi_get

[danmayer]

Ok, this is a bit silly, but after our conversation I was curious how much we could reduce allocations in the get multi tight loop... This does reduce allocations which is nice, but the overall benchmark doesn't show much of a difference... Still kind of fun to poke around at, and it might be nice to add a check to CI that ensures we keep pushing allocations down for our commands.

allocations before: 1944
allocations after: 1659

benchmark before:

❯❯❯$ BENCH_TARGET=get_multi RUBY_YJIT_ENABLE=1 bundle exec bin/benchmark  
  yjit: true  
  ruby 3.3.4 (2024-07-09 revision be1089c8ec) +YJIT [arm64-darwin23]  
  Warming up --------------------------------------  
          get 100 keys    68.000 i/100ms  
  get 100 keys raw sock  
                          84.000 i/100ms  
  Calculating -------------------------------------  
          get 100 keys    581.042 (±13.3%) i/s    (1.72 ms/i) -      5.780k in  10.118846s  
  get 100 keys raw sock  
                          685.477 (±18.5%) i/s    (1.46 ms/i) -      6.636k in  10.014161s  
  Comparison:  
  get 100 keys raw sock:      685.5 i/s  
          get 100 keys:      581.0 i/s - same-ish: difference falls within error

benchmark after:

❯❯❯$ BENCH_TARGET=get_multi RUBY_YJIT_ENABLE=1 bundle exec bin/benchmark 
yjit: true
ruby 3.3.4 (2024-07-09 revision be1089c8ec) +YJIT [arm64-darwin23]
Warming up --------------------------------------
        get 100 keys    67.000 i/100ms
get 100 keys raw sock
                        89.000 i/100ms
Calculating -------------------------------------
        get 100 keys    633.133 (±14.2%) i/s    (1.58 ms/i) -      6.164k in  10.010311s
get 100 keys raw sock
                        760.185 (±21.7%) i/s    (1.32 ms/i) -      7.209k in  10.066808s
Comparison:
get 100 keys raw sock:      760.2 i/s
        get 100 keys:      633.1 i/s - same-ish: difference falls within error

paired with Aaron and was able to cut allocations in half... while it still doesn't show up as much in a micro benchmark this should add up across all cache calls across all web requests. The new method is a bit harder to understand, but feels worth it for such a frequently used tight loop.

before: 1944
after: 851

[tenderworks]

Only a couple comments, but nothing that should block this PR as-is.

[danmayer]

Note: this is the optimized get multi only use for single server with raw mode... we should run tests in deployed systems (staging) before merging

[danmayer]

this removes an additional allocation for all the non multi calls