feat: reuse prepared search configurations

[foxspy]

issue: #1722

Summary

• add an opt-in Search path for shared immutable prepared configurations
• cache the latest prepared configuration by exact JSON equality with concurrent miss deduplication
• preserve the existing Search path for index implementations that do not opt in
• add reuse, invalidation, and concurrency coverage

[sre-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: foxspy

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [foxspy]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[alexanderguzhva]

@foxspy This problem makes me wonder why it is needed to pass a raw json into Index<T>::Search() function. Wouldn't it better to expose it to the external caller in the following way:

auto version = knowhere::Version::GetCurrentVersion().VersionNumber();
auto index = knowhere::IndexFactory::Instance().Create<T>(index_type, version);

// create a dedicated config object?
auto config = CreateConfigFromJson(json);
// modify the config
...

// the search
auto search_result = index->Search(dataset, config, bitset, op_context);

Otherwise, every search operation is going to perform a json comparison operation, which is a recursive comparison of std::map<std::string, json>.
Also, std::hash<nlohmann::json> is available.
Also, according to the introduced code, it caches only 1 parsed json object.

So, maybe something like the following? Maybe, even hash is not needed.

struct JsonConfig {
    // used for the fast comparison
    uint64_t hash;
    nlohmann::json json;

    static JsonConfig CreateConfigFromJson(const nlohmann::json& input_json) {
        // save json and compute hash using std::hash<nlohmann::json>
    }

    const json& get_json() const { return json; }
};

I'm just wondering whether this config caching needs to be built right inside the knowhere.

---

On the other hand, the solution is totally acceptable if you'd like to avoid parsing a single json that it unlikely to change, and it is too complicated to make a complex solution.