GCF: Add Slack sample + clean up imports

[ace-n]

Do not merge until this has actually been tested with Slack.

(@lesv I added you since Kurtis is OOO - LMK if I should ping someone else!)

[lesv]

PTAL
I've sent you a list of books. The main one is Effective Java 3rd ed.
If your POM inherits from our shared-configuration:

<dependency>
<groupId>com.google.cloud.samples</groupId>
<artifactId>shared-configuration</artifactId>
<version>1.0.12</version>
<type>pom</type>
</dependency>

You should be able to domvn checkstyle:check.

[ace-n]

I had to disable surefires automatic testing via skipTests in pom.xml to deploy the code. (The tests rely on environment variables, which aren't provisioned until the tests finish on GCF - a catch-22.)

That seems to disable local tests too (e.g. when mvn clean verify is called), which is not what I wanted. I assume we can disable tests only on GCF deploys, but I don't know what the best way to do this is.

(Arguably, the GCF deployment process shouldn't be calling test goals.)

[ace-n]

(Related question: should we document how to include files alongside your function like we do for other languages?)

[lesv]

re-disabling surefire, we should enable but set appropriate defaults so users can run.

[lesv]

Once you figure out surefire, LGTM

[ace-n]

I've tried to trigger profiles (for "only test locally" purposes) based on three things:

1. Maven archetypes - the Java functions framework deploys the function using mvn functions:deploy as shown here. However, this StackOverflow post says goal-dependent triggering is not possible.
2. Environment variables - these are set after the function build (and test run) is complete, so you can't use them as a proxy for "am I on dev or prod?" (Alternatively, we could check for env variables that are defined on a user's system regardless of OS - e.g. $HOME or $SHELL)
3. File presence - if .gcloudignore is present, run the tests. This does work, but it seems kinda hacky - especially vs. option 1.

@lesv thoughts?

May 2020 update: we decided to go with env-var-based profiles, specifically skipping tests when env.NEW_BUILD is defined (which is the case on Cloud Functions, but not Cloud Build).