Looks good. This shouldn't change any functionality and only add a slight overhead for virtual function calls but is much easier to reason about

Feeling good about including this after 5.3.0 since API doesn't change.

This is included in master now. 🎉

I re-read this PR in the contex of #2926. I cannot see any obvious problems that would cause an increase in memory usage. But I notice that locks are used when the GetLuaContext is called. Therefore I wonder if GetLuaContext were called a more often then more locking could cause less efficient allocation and therefore memory growth. Just a hunch, but going on this hunch I looked in the PR to see if more locks could be happening...

It seems like the answer is yes, but not many more. Would appreciate others eyes to rule this out. For example here the context was previously accessed once and then used in util::luaFunctionExists and RestrictionParser directly. After this PR the code is much cleaner but the context is accessed once when SetupSources() is called and a second time when RestrictionParser is created (due to the usage of scripting_environment.GetProfileProperties() inside its constructor). Now, creating the context twice rather than once may have no realworld performance penalty at all. But maybe it could? Or maybe there are other spots in the code that more locks are happening that I don't notice? //cc @kkaefer @MoKob @karenzshea