Port ScalarField, AsyncFieldMixin and friends to rust

[tobni]

The real juice is in porting SourcesField and what that unlocks. This is a stepping stone, hopefully worth the squeeze.

This additionally marks Field as frozen, allowing to avoid additional ref-counting overhead.

Still noticable in our 26k python, 100 JS file file repo

hyperfine --warmup 1 --runs 3 \                                                         
        -n 'main' \                                                                                                             
        --prepare 'git -C <redacted>/pants checkout main --quiet' \                                                      
        'PANTS_SOURCE=<redacted>/pants PYENV_VERSION=pants@3.14.3 pants --no-pantsd dependencies :: > /dev/null' \     
        -n 'branch' \                                                                                                           
        --prepare 'git -C <redacted>/pants checkout add/port-scalar-and-async-mixin-fields --quiet' \                  
        'PANTS_SOURCE=<redacted>/pants PYENV_VERSION=pants@3.14.3 pants --no-pantsd dependencies :: > /dev/null' \     
        2>&1)
  ⎿  Benchmark 1: main
       Time (mean ± σ):     35.261 s ±  1.261 s    [User: 40.704 s, System: 12.371 s]
       Range (min … max):   34.021 s … 36.542 s    3 runs
      
     Benchmark 2: branch                                                                                                        
       Time (mean ± σ):     33.615 s ±  0.202 s    [User: 38.675 s, System: 12.403 s]
       Range (min … max):   33.478 s … 33.847 s    3 runs      

[tobni]

We cannot rely on typehints for help info on fields that are implemented in pyo3. I find this solution more appropriate than trying to update __annotations__ in other ways.

[benjyw]

Would be good to comment here about when we expect raw_value to exist and when we don't. I.e., that that it's not arbitrary, but that we have two well-defined cases.

[tobni]

Field's __hash__ combined two hashes with bitwise AND. AND biases every bit toward 0 (75% chance per bit), so the output clusters near zero. Since CPython picks hash table buckets from the low-order bits, this clustering means more entries land in the same buckets, turning O(1) lookups into chain walks. With two AND'd hashes, you lose ~12 bits, roughly equivalent to a hash table running at 4096x its expected collision rate.

[benjyw]

Yikes, that is a huge facepalm

[benjyw]

How much of the perf benefit might be attributable to fixing this?

[tobni]

I haven't measured, this was a drive by when implementing AsyncFieldMixin's hash.

[benjyw]

LGTM!

To avoid CI churn, feel free to merge as-is and jam that comment I asked for on top of a future follow up PR.

[benjyw]

Would be good to comment here about when we expect raw_value to exist and when we don't. I.e., that that it's not arbitrary, but that we have two well-defined cases.