Add support for VAMANA index algorithm at index creation

[mgravell]

Note: the existing API only used Dictionary<string, object> attributes, which means that we could just add the enum addition and call it a day, and let the user worry about making everything work. However, it seems sensible to help the user out by providing an extended API with proper support for the options specific to each type, so:

• add structured object-model for complex vector index creation, with specialized types for the 3 vector types
  • add VectorField.Dimensions, .Type and .DistanceMetric
  • add mechanism to bake those into command without breaking existing usage
    • AddDirectAttributes, DirectAttributeCount
  • new type FlatVectorField
  • new type HnswVectorField
  • new type SvsVanamaVectorField
• make it possible to extract approx command from SerializedCommand.ToString()
• add implicit operator from string to FieldName to reduce new overloads needed
• add new Schema.Add*VectorField APIs
• add tests to demonstrate correct index construction

Open design question: I've used "human" names in place of M, EF_CONSTRUCTION, etc; - and EuclideanDistance instead of L2 - is this agreeable? or should it be left "raw"?

Side: this fixes a broken test; in the existing logic, if attributes is not specified, then <index_attribute_count> (i.e. 0) is never added. In reality this won't break any working code because attributes is pretty-much needed (because that's the only way to specify DIM etc in the existing API)

[atakavci]

LGTM, just one nit.
and for your question around naming,, i believe there's significant value in keeping naming similar/closer -if not exact- across client and server boundaries.
That allows developers to quickly and instinctively map/correlate functionality when working with both sides of the application, especially during root causing issues or feature development. But this is rather a strategical desicion rather than my personal opinion on naming,, also aligning across libraries is a factor too.
So lets get more people involved into a conversation around this.

[atakavci]

nit: use of special chars break the IDE shows docs and hints. This also shows up as tons of warnings on github PR review page.

[mgravell]

done

[uglide]

While I agree with Ali, for the builders, we can use more human-friendly names to improve DevEx. One note though, we should reference "raw names" in docstrings to help humans and LLMS to pick up appropriate attributes, enum values, etc

[uglide]

Please update the doc strings to refer to Redis "raw" names.

[mgravell]

done

[mgravell]

LGTM, just one nit. and for your question around naming,, i believe there's significant value in keeping naming similar/closer -if not exact- across client and server boundaries. That allows developers to quickly and instinctively map/correlate functionality when working with both sides of the application, especially during root causing issues or feature development. But this is rather a strategical desicion rather than my personal opinion on naming,, also aligning across libraries is a factor too. So lets get more people involved into a conversation around this.

it is also possible to duplicate enum values in C#, i.e.

public enum VectorDistanceMetric {
   ...
   EuclideanDistance = 1,
   L2 = EuclideanDistance,
   // ...
}

with the result that VectorDistanceMetric.L2 and VectorDistanceMetric.EuclideanDistance both work, and are identical. The fun question is "what is someEnum.ToString() ? " - the simple answer is that it is undefined, and changes in different runtimes and platforms - but that doesn't impact our use, because the code does a switch itself (for other reasons; stability here is just a nice side-effect)

Not saying we should / shouldn't do that - just one more thing to consider.