Add contributing guidance for logging when handling exceptions

[jack-berg]

We actually have inconsistent and probably bad patterns around this in other places:

In these cases we log both the exception message and record the the exception itself:

opentelemetry-java/exporters/common/src/main/java/io/opentelemetry/exporter/internal/grpc/GrpcExporter.java

Lines 133 to 134 in 9a992c2

	+ e.getMessage(),
	e);

opentelemetry-java/exporters/common/src/main/java/io/opentelemetry/exporter/internal/http/HttpExporter.java

Lines 119 to 125 in 9a992c2

	logger.log(
	Level.SEVERE,
	"Failed to export "
	+ type
	+ "s. The request could not be executed. Full error message: "
	+ e.getMessage(),
	e);

opentelemetry-java/sdk-extensions/jaeger-remote-sampler/src/main/java/io/opentelemetry/sdk/extension/trace/jaeger/sampler/JaegerRemoteSampler.java

Lines 130 to 136 in 9a992c2

	logger.log(
	Level.SEVERE,
	"Failed to execute "
	+ TYPE
	+ "s. The request could not be executed. Error message: "
	+ e.getMessage(),
	e);

In these cases we include the stringified caught exception message and don't record the exception, preventing the user from seeing the stacktrace:

opentelemetry-java/sdk-extensions/autoconfigure-spi/src/main/java/io/opentelemetry/sdk/autoconfigure/spi/internal/DefaultConfigProperties.java

Lines 184 to 185 in 9a992c2

	throw new ConfigurationException(
	"Invalid duration property " + name + "=" + value + ". " + ex.getMessage());

opentelemetry-java/sdk-extensions/autoconfigure/src/main/java/io/opentelemetry/sdk/autoconfigure/AutoConfiguredOpenTelemetrySdkBuilder.java

Lines 504 to 505 in 9a992c2

	logger.warning(
	"Error closing " + closeable.getClass().getName() + ": " + ex.getMessage());

opentelemetry-java/opentracing-shim/src/main/java/io/opentelemetry/opentracingshim/TracerShim.java

Lines 110 to 114 in 9a992c2

	logger.log(
	Level.WARNING,
	"Exception caught while extracting span context; returning null. "
	+ "Exception: [{0}] Message: [{1}]",
	new String[] {e.getClass().getName(), e.getMessage()});

opentelemetry-java/sdk-extensions/incubator/src/main/java/io/opentelemetry/sdk/extension/incubator/fileconfig/DeclarativeConfiguration.java

Lines 290 to 291 in 9a992c2

	logger.warning(
	"Error closing " + closeable.getClass().getName() + ": " + ex.getMessage());

opentelemetry-java/sdk/metrics/src/main/java/io/opentelemetry/sdk/metrics/SdkDoubleHistogram.java

Lines 97 to 98 in 9a992c2

	logger.warning("Error setting explicit bucket boundaries advice: " + e.getMessage());
	return this;

opentelemetry-java/sdk/metrics/src/main/java/io/opentelemetry/sdk/metrics/SdkLongHistogram.java

Line 102 in 9a992c2

logger.warning("Error setting explicit bucket boundaries advice: " + e.getMessage());

We should add some guidance to https://github.com/open-telemetry/opentelemetry-java/blob/main/CONTRIBUTING.md#best-practices-that-we-follow to recommend not stringifying the exception and recording the exception using dedicated log overloads.

Originally posted by @jack-berg in #8216

[VamshikrishnaMonagari]

@jack-berg I opened a PR that addresses the patterns you called out here. It covers all the cases listed and also adds a best practice note to CONTRIBUTING.md. I intentionally left out DefaultConfigProperties.java since that one is constructing a thrown exception rather than a logger call. Happy to make any changes if needed!