Include `flogger-system-backend` in library pom as a runtime dep

[anguillanneuf]

If we make flogger-system-backend a runtime dependency in google-cloud-pubsublite/pom.xml, do we still need to specify it for samples? The goal is to clean up dependencies in the samples pom.xml if possible:

java-pubsublite/samples/snippets/pom.xml

Lines 44 to 64 in 30a276b

	<!-- [START pubsublite_install_without_bom] -->
	<!-- [START pubsublite_java_dependencies] -->
	<dependency>
	<groupId>com.google.cloud</groupId>
	<artifactId>google-cloud-pubsublite</artifactId>
	<version>0.2.0</version>
	</dependency>
	<dependency>
	<groupId>com.google.cloud</groupId>
	<artifactId>google-cloud-pubsub</artifactId>
	<version>1.108.1</version>
	</dependency>
	<!-- A logging dependency used by the underlying library -->
	<dependency>
	<groupId>com.google.flogger</groupId>
	<artifactId>flogger-system-backend</artifactId>
	<version>0.5.1</version>
	<scope>runtime</scope>
	</dependency>
	<!-- [END pubsublite_java_dependencies] -->
	<!-- [END pubsublite_install_without_bom] -->

Cc: @BenWhitehead

[dpcollins-google]

The thing is, I don't think flogger-system-backend is a runtime dep. SOME system backend is, but it could just as easily be a remote logger instead of a stdout one

[BenWhitehead]

Part of the issue as the pom.xml stand right now is that it is not possible for a user to run the pubsub lite client without picking a flogger backend due to the following exception being thrown.

java.lang.ExceptionInInitializerError
  at com.google.common.flogger.backend.Platform.getCallerFinder(Platform.java:160)
  at com.google.common.flogger.GoogleLogger.forEnclosingClass(GoogleLogger.java:48)
  at com.google.cloud.pubsublite.internal.wire.RetryingConnectionImpl.<clinit>(RetryingConnectionImpl.java:48)
  at com.google.cloud.pubsublite.internal.wire.PublisherImpl.<init>(PublisherImpl.java:109)
  at com.google.cloud.pubsublite.internal.wire.PublisherImpl.<init>(PublisherImpl.java:129)
  at com.google.cloud.pubsublite.internal.wire.PublisherBuilder$Builder.build(PublisherBuilder.java:129)
  at com.google.cloud.pubsublite.internal.wire.SinglePartitionPublisherBuilder$Builder.build(SinglePartitionPublisherBuilder.java:73)
  at com.google.cloud.pubsublite.internal.wire.RoutingPublisherBuilder$Builder.build(RoutingPublisherBuilder.java:76)
  at com.google.cloud.pubsublite.cloudpubsub.PublisherSettings.instantiate(PublisherSettings.java:100)
  at com.google.cloud.pubsublite.cloudpubsub.Publisher.create(Publisher.java:26)
  at com.google.cloud.testing.PubSubLiteTesting.publishMessages(PubSubLite.java:113)
  ...

It is correct that a user could choose to pick a different backend for their environment, but right now we're pushing an incomplete library definition. With maven, gradle etc it's possible for a user to exclude a library and swap to a different backend if they prefer it.

For those users which are using std/err logging (which is the vast majority) I think it makes sense to provide a default backend which works out of the box.

The above exception can be seen by trying to run the "Publishing Messages" code sample here with the following pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>com.google.cloud.testing</groupId>
  <artifactId>pubsub-lite-testing</artifactId>
  <version>0.1.0-SNAPSHOT</version>

  <properties>
    <maven.compiler.target>1.8</maven.compiler.target>
    <maven.compiler.source>1.8</maven.compiler.source>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  </properties>

  <dependencies>
    <dependency>
      <groupId>com.google.cloud</groupId>
      <artifactId>google-cloud-pubsublite</artifactId>
      <version>0.2.0</version>
    </dependency>
  </dependencies>
</project>