Proposed Opentracing TCK Core Implementation This PR proposes the core of the opentracing TCK implementation for discussion. Highlights: - Assumes that the application server under test provides a [MockTracer](https://github.com/opentracing/opentracing-java/tree/master/opentracing-mock) to the test application. Based on the opentracing spec, this is `@Inject`ed into the `Tracer` in the JAXRS `org.eclipse.microprofile.opentracing.tck.application.TestWebServices` class. In addition to a "Hello World" JAXRS endpoint that will be tested, this class has a method named `getTracer` which will be called by the Arquillian client to return the information stored in the `MockTracer` so that the client can assert the expected opentracing spans. In addition, this class has a method named `clearTracer` which can be called in between tests to clear the `MockTracer`. - The method `TestWebServices.getTracer` uses reflection to access the information of the `MockTracer`. The reason this is done instead of bringing in the `io.opentracing:opentracing-mock` dependency directly and casting the `Tracer` to `MockTracer` is that we don't want to assume that the application's classloader has visibility into the classloader that created the `Tracer` (if there is no such visibility, a `ClassCastException` will occur). - The method `TestWebServices.getTracer` converts the data in the `MockTracer` into a `TestTracer` and `TestSpan`s which abstracts out the logical information in the `MockTracer` (this is also needed because `MockTracer` is not a POJO so its data is not transparently serialized by `Jackson`). - The class `org.eclipse.microprofile.opentracing.tck.OpentracingClientTests` is the `Arquillian` test class. In the `createDeployment` method, we generate the WAR that gets installed into the target application server. - There is a single test, `simpleTest` which has the `@RunAsClient` annotation meaning it will run in the `Arquillian` test harness and act as the JAXRS client. In `executeHelloWorld`, we get get the remote `TestTracer` and call its `spanTree` method which returns a `TestSpanTree`. This converts all of the spans into a tree data structure which allows for easier comparison (to assert equality) and also overrides `toString` to print out a JSON-like representation of the tree of spans (if the equality assertion fails, it's nice to compare the trees to see what's different). - Finally we build a simulated `TestSpanTree` of the spans that we expect the response to give, and we assert equality between the two. The `TestSpanTree` and its tree of `TestSpan`s override `equals` to recursively perform the comparison based on the number of spans at each level and the spans' operation name and span kind attributes. Signed-off-by: Kevin Grigorenko <kevin.grigorenko@us.ibm.com>