METRON-712: Separate evaluation from parsing in Stellar

[cestella]

Description

With the current implementation of Stellar, we cannot cache the parse tree and then apply it after the fact. It's just an artifact of how we do the parsing: we actually execute the statement as we parse rather than constructing an AST that can then be evaluated later given a message. Essentially what I'm proposing is that we build the equivalent of Pattern.compile() in Java except for Stellar.
We should for multiple reasons:

• code clarity - decoupling the stellar language from the generated parser code
• performance - saving lexing and parsing for every message. Also, the resulting parse-stack may be much smaller than the somewhat complex.

In this PR, I have added a google cache that will cache the resulting compiled expression in BaseStellarProcessor for 10 minutes (by default). I have also created a microbenchmarking suite and have evaluated this on a few representative expressions.
Results:

• TO_UPPER('casey')
  • Median ms before: 880.5
  • Median ms after: 15
  • Speedup: 58.6x faster
• TO_LOWER(name)
  • Median ms before: 497
  • Median ms after: 3
  • Speedup: 165.6x faster
• 1 + 2*(3 + int_num) / 10.0
  • Median ms before: 676
  • Median ms after: 4
  • Speedup: 169x faster
• 1.5 + 2*(3 + double_num) / 10.0
  • Median ms before: 634
  • Median ms after: 1
  • Speedup: 634x faster
• if ('foo' in ['foo']) OR one == very_nearly_one then 'one' else 'two'
  • Median ms before: 616
  • Median ms after: 23
  • Speedup: 26x faster
• 1 + 2*(3 + int_num) / 10.0
  • Median ms before: 601
  • Median ms after: 2
  • Speedup: 300.5x faster
• DOMAIN_TO_TLD(domain)
  • Median ms before: 505
  • Median ms after: 16
  • Speedup: 32.5x
• DOMAIN_REMOVE_SUBDOMAINS(domain)
  • Median ms before: 496
  • Median ms after: 11
  • Speedup: 45x faster

Testing Plan

Please refer to the METRON-744 PR testing plan.

In order to streamline the review of the contribution we ask you follow these guidelines and ask you to double check
the following:

For all changes:

• Is there a JIRA ticket associated with this PR? If not one needs to be created at Metron Jira.
• Does your PR title start with METRON-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.
• Has your PR been rebased against the latest commit within the target branch (typically master)?

For code changes:

• Have you included steps to reproduce the behavior or problem that is being changed or addressed?
• Have you included steps or a guide to how the change may be verified and tested manually?
• Have you ensured that the full suite of tests and checks have been executed in the root incubating-metron folder via:

mvn -q clean integration-test install && build_utils/verify_licenses.sh 

• Have you written or updated unit tests and or integration tests to verify your changes?
• If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
• Have you verified the basic functionality of the build by building and running locally with Vagrant full-dev environment or the equivalent?

For documentation related changes:

• Have you ensured that format looks appropriate for the output in which it is rendered by building and verifying the site-book? If not then run the following commands and the verify changes via site-book/target/site/index.html.

cd site-book
bin/generate-md.sh
mvn site:site

Note:

Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible.
It is also recommened that travis-ci is set up for your personal repository such that your branches are built there before submitting a pull request.

[cestella]

TODO: Run this up in vagrant. I can't do so now as I am on hotel wifi, so it'll be this Thursday before I get a chance.

[mmiklavc]

+1 Nice addition @cestella. I didn't run the benchmarks, but I did run through the full test plan in Vagrant quick-dev.