fix: schemaVersion called with old context

[willhausman]

Fix for #294

If you override schemaVersion(context), context is not the current request's context. This is because the schemaVersion() called in CompilerApi is a closure. By adding the schemaVersion to the key for the compilerCache, CompilerApi will effectively recompile with new schemaVersions.

Note: If the server has not specified a maxCompilerCacheKeepAlive, the old compilers will remain in memory until compilerCacheSize is reached. At that point, the LRU cache will start evicting the old schemas.

Note for OrchestratorApi: Current workaround for incorrect context in schemaVersion is to tack the schemaVersion into your contextToAppId. This introduces many OrchestratorApis when there should be far fewer. Passing the correct context to schemaVersion(context) resolves this issue.

Note for CompilerApi: This was left untouched to allow customizations directly calling createCompilerApi to still behave the same without a call to schemaVersion(context), and because options.devServer is handled there. It's starting to feel messy, so probably schemaVersion needs to be restructured overall.

[paveltiunov]

@willhausman Hey Will! Thanks for contributing this! Let's reiterate on this one: could you please provide example scenario, explanation of a problem and how it is solved by this change. Preferably with implementations of affected functions and values they return on each request just to make sure we're thinking about the same problem.

[willhausman]

Created #294 with more detail. This implementation is one way I envision it can be solved.

[willhausman]

Now simply passes current context along through CompilerApi to schemaVersion.

[paveltiunov]

@willhausman Looks good! The only thing: can we set schemaVersion for CompilerApi in getCompilerApi method instead of adding additional arguments to all methods? It'll be a little bit less changes and api-gateway won't be involved. We can introduce explicit setter for schemaVersion in CompilerApi for that.

[paveltiunov]

@willhausman Looks great! Thanks for contributing this one!