Adds session option to cache query plans

[rafael]

Motivation

• Recently we ran into some issues due to query plan cache in vtgate growing too fast and causing OOM errors in the machine. It turned out, that in this context we don't need to be caching query plans.

• This commit adds a new option to ExecuteOptions. It allows clients to set a
  session variable to not cache query plans.

• If you are using mysql server plugin, you can set this variable with:

  set skip_query_plan_cache=1 
  

• By default, all query plans are cached (existent behavior)

Open Questions

• Is it possible to pass this variable at connection time? If we could do something similar toCLIENT_FOUND_ROWS, it would be way more convenient. However, I didn't find a clear path to support this :(
• Should we also use this setting to not cache query plans in tablets?

Tests

• Locally and unit tests

[demmer]

Although this was the option we discussed IRL, as a general rule I try to avoid having the "negative" case encoded in options, even when it is the default.

In other words, I think we should change this so the exposed option is set cache_query_plan with a default value of 1.

[demmer]

This is a mouthful and the "FromSession" is implicit in the function signature.

Also in light of the above comment, I'd change this to be func shouldCacheQueryPlan(session *vtgatepb.Session) bool

[demmer]

Note that even if we switch the exposed set option, this needs to stay as-is so that the default value in the ExecuteOptions protobuf stays 0.

[demmer]

Is it possible to pass this variable at connection time? If we could do something similar toCLIENT_FOUND_ROWS, it would be way more convenient. However, I didn't find a clear path to support this :(

Not that I know of

Should we also use this setting to not cache query plans in tablets?

Yes!

[rafael]

@demmer addressed most of the comments. I have one comment about:

set cache_query_plan

I agree with the idea and I also try to avoid negative options. However, in this case I would argue we should keep it like this to be consistent. If no_cache_query_plan in the proto definition were private, it would be different. Given that someone using the grpc protocol will still have to set no_cache_query_plan, I think it's better to keep it consistent between the two. What do yo think?

[rafael]

Addressed negative option by renaming no_cache_query_plan to skip_query_plan_cache

[demmer]

Looks great to me!
@sougou ?

[sougou]

Change looks good. Can you rebase against the latest master first and make sure all the tests pass? I worry that the latest dedup improvements may affect some tests.

[rafael]

I had a bad rebase and I think @googlebot got confused. It should be good now :)