Speed: Abstract out function call.

Previously ran 30x for a 23ms hit in vvv, let’s abstract it out to only
run once.
Remove a `file_exists` check.

This is called about 44 times in a front-end request, adding about 33ms
on the load time.  We shouldn’t ever be calling get_module() on
something that doesn’t exist anyway, so a Warning being generated by
the `fopen` inside `get_file_data` is fine (and probably useful, as it
will no longer fail silently)
Speed: cache available modules in an option

The cache is invalidated:

- when Jetpack is updated
- when an admin page is loaded

It's disabled for admin pages and in development mode
Jetpack: Cache file_data in an option.

And index it by version.

This saves about 105 ms (it had been less previously, but when we
removed the prior `file_exists` checks, the `fopen` calls in
`get_file_data` went up.)

This does mean that we’ll probably need some sort of way to turn this
off when in active development, so changes we make to the module
headers actually get seen.  Maybe compare it on the admin side to the
real headers if `?page=jetpack` — unsure.
Jetpack_Options: Pass $default to get_option

If non-compressed.
Minor refactor of caching available modules.

Old way we were purging the option on plugin update, this way, we’re
basically updating it if it’s changed on every admin view.

We’re also storing it in an array key of the option, so versions never
cross the streams.
Whitespace aligning.
Refresh the file_data cache on JP admin pages
Speed: Abstract out function call.

Previously ran 30x for a 23ms hit in vvv, let’s abstract it out to only
run once.
Remove a `file_exists` check.

This is called about 44 times in a front-end request, adding about 33ms
on the load time.  We shouldn’t ever be calling get_module() on
something that doesn’t exist anyway, so a Warning being generated by
the `fopen` inside `get_file_data` is fine (and probably useful, as it
will no longer fail silently)
Speed: cache available modules in an option

The cache is invalidated:

- when Jetpack is updated
- when an admin page is loaded

It's disabled for admin pages and in development mode
Jetpack: Cache file_data in an option.

And index it by version.

This saves about 105 ms (it had been less previously, but when we
removed the prior `file_exists` checks, the `fopen` calls in
`get_file_data` went up.)

This does mean that we’ll probably need some sort of way to turn this
off when in active development, so changes we make to the module
headers actually get seen.  Maybe compare it on the admin side to the
real headers if `?page=jetpack` — unsure.
Minor refactor of caching available modules.

Old way we were purging the option on plugin update, this way, we’re
basically updating it if it’s changed on every admin view.

We’re also storing it in an array key of the option, so versions never
cross the streams.
Whitespace aligning.
Refresh the file_data cache on JP admin pages
Merge branch 'speed' of https://github.com/Automattic/jetpack into speed
Merge pull request #964 from Automattic/speed

Jetpack Meetup Project: SPEED!