Remove unnecessary locking in Crypters

[barreeeiroo]

General items:

• I have updated the relevant documentation files under docs/
• My code follows the:
  • Google Java style guide (for .java files)
  • Google JavaScript style guide (for .js files)
• ant tests passes on my machine

If your code changes how something works on the device (i.e., it affects the companion):

• I branched from ucr
• My pull request has ucr as the base

Further, if you've changed the blocks language or another user-facing designer/blocks API (added a SimpleProperty, etc.):

• I have updated the corresponding version number in appinventor/components/src/.../common/YaVersion.java
• I have updated the corresponding upgrader in appinventor/appengine/src/.../client/youngandroid/YoungAndroidFormUpgrader.java (components only)
• I have updated the corresponding entries in appinventor/blocklyeditor/src/versioning.js

For all other changes:

• I branched from master
• My pull request has master as the base

What does this PR accomplish?

Description

This PR removes an unnecessary syncronized call (effectively removing locking) from the OdeAuthFilter and GalleryToken classes.

The interesting change is on OdeAuthFilter, which was being used as the authentication filter through the following stacktrace: getCrypter <- getUserInfo <- doFilter. In the previous implementation, even though the crypter was initialized, getting a reference to it was effectively single-threaded, but it is actually just used for a singleton initialization.
By instead adding the extra null check outside the syncronized block, we achieve yielding the initialized crypter without making this method single threaded when not needed.

I suspect OdeAuthFilter is currently acting single-threaded, so this change in theory should improve performance. Not sure for how much though, as it's just the part to acquire the crypter, but it should improve somewhat.

[ewpatton]

Note that rather than do this, we could initialize it in a class static block, which will run when the class loader loads the class. In that case, we should also make it private static final since it should never change.

Alternatively, if Crypter isn't reentrant then we may want to make a ThreadLocal crypter instead.

[barreeeiroo]

The reason why I prefer to use the volatile option rather than a static initialization is because I saw another issue when working on the Tomcat implementation. See the following file: https://github.com/barreeeiroo/appinventor-sources/blob/tomcat/appinventor/appengine/src/com/google/appinventor/server/OdeAuthFilter.java (ignore the lack of volatile in there, it's a miss).

I had a lot of issues reading the authkey from Tomcat, probably because of how the webapps path works in there. I had to implement a custom file reader using the ServletContext, which gave me the real path (rather than the default deployment in webapps).

Another option is to directly initialize it from the init call, but this requires ensuring that crypter is never needed during a static call, which right now is not satisfied given the getUserInfo call pattern.