Add support for configuring HNSW parameters

[mayya-sharipova]

This PR extends the dense_vector type to allow configure HNSW params in
index_options:
m – max number of connections for each node,
ef_construction – number of candidate neighbors to track while searching
the graph for each newly inserted node.

"mappings": {
  "properties": {
    "my_vector": {
      "type": "dense_vector",
      "dims": 128,
      "index": true,
      "similarity": "l2_norm",
      "index_options": {
        "type" : "hnsw",
        "m" : 15,
        "ef_construction" : 50
      }
    }
  }
}

index_options as an object is optional. If not provided, the default values from the
current codec will be used.

Relates to #78473

[elasticmachine]

Pinging @elastic/es-search (Team:Search)

[jtibshirani]

This makes sense to me as a short-term solution. (We discussed offline that in the medium-term, we want to add a more general/ elegant way for field mappers to add codec configuration.)

I left some small comments and had these bigger ones:

• Right now the marker interface VectorFieldMapper contains important logic, so now parsing logic is split across DenseVectorFieldMapper and VectorFieldMapper. Could we just contain it all in DenseVectorFieldMapper to keep it simple? Then the marker interface would have just one method getKnnVectorsFormatForField.
• Instead of a very general name like VectorFieldMapper, we could name it something specific like PerFieldKnnVectorsFormatFieldMapper. This makes it clear it exists for just one purpose and is not a general vector interface that other field mappers should extend. We could even put a big comment like "for internal use only" so no plugin authors are tempted to use it. This is not elegant but feels like an okay short-term solution.

[jtibshirani]

If m or ef_contruction are not provided, the default values from the
current codec will be used.

One last thought: I think we could keep the config really simple and always require all parameters (type, m, ef_construction) to be specified if there is an index_options section. I don't see a benefit in allowing just one to be overridden: if you are tuning parameters, you will almost always be considering both?

[mayya-sharipova]

@jtibshirani Thanks for a great feedback. I've tried to address your comments in d5cc59f. Please continue to review when you have time.

[jtibshirani]

This is looking good to me, I left some final small comments.

[mayya-sharipova]

@jtibshirani Thanks for another round of review. I've tried to addressed your second round of feedback in db231e9. Please continue to review when you have time.

[jtibshirani]

Thanks @mayya-sharipova !

[mayya-sharipova]

@elasticmachine run elasticsearch-ci/part-1