Revert "Optimise Ajv cache usage"

[0bex0]

Reverts #1062

Comment highlighted issues with the ajv library which make this fix redundant, while inadvertently adding extra memory usage by using a secondary cache which is not used.

[cdimascio]

@0bex0 curious whether you've created an issue with ajv regarding the double caching. Would love to solve it there, upgrade the dep, and retain your fix (assuming it's feasible within a quick timeframe)

[cdimascio]

Alternatively, we might maintain our own cache, essentially compile the schema on first use, then cache the schema via a map owned by the validator, rather than using ajv's addSchema.

Essentially, this approach https://ajv.js.org/guide/managing-schemas.html#caching-schemas-in-your-code

[0bex0]

Alternatively, we might maintain our own cache, essentially compile the schema on first use, then cache the schema via a map owned by the validator, rather than using ajv's addSchema.

Essentially, this approach https://ajv.js.org/guide/managing-schemas.html#caching-schemas-in-your-code

The ajv.compileAsync call still caches the full schema object and SchemaEnv object within the ajv instance. The whole point of this internal cache is to avoid the re-compilation of schemas, but it's dependent on the exact same object reference for a schema to be used for the cache to actually work, which does not work with the express-openapi-validator implementation, since the same object reference is never used for any two schemas due to the logic in Validator._schemaBody.

I'm not sure (without any updates to the ajv library) there's a simple way to improve the memory usage w.r.t to the caching in this library at the moment. I'm going to raise an issue in the ajv library to at least fix the double caching and then this fix is retained, that would at least abate the problem of using the whole schema object as a cache key.

[0bex0]

I have added an issue here: ajv-validator/ajv#2554 (comment) and will address it in due course. This may not be possible until next week due to other commitments, but I have a fix in mind, yet to test it.

[0bex0]

In order to be backwards compatible, the double caching logic has to stay in place in the Ajv library, however I proposed adding an instance option which would allow users more flexibility w.r.t to how they choose to cache SchemaEnv objects.