Split errors jar into client and server jars

[pnepywoda]

https://github.com/palantir/conjure-java-runtime-api/blob/develop/errors/src/main/java/com/palantir/conjure/java/api/errors/RemoteException.java should be in it's own jar - it's only necessary to use when constructing errors from http BODYs. Defining errors, e.g. ErrorType and SerializableError, have nothing to do with http BODY interpretation.

This should help with versioning the client/server parts of error handling independently.

[iamdanfox]

This seems nice from a conceptual perspective, but for the http-remoting -> conjure-java-runtime migration, I don't think it's quite sufficient as the unwanted jars could end up on your compile classpath transitively from a variety of different places.

The current least-worst option I can think of is to add a gradle/ban-remoting-api.gradle file, with the following contents:

// Apply this snippet to all your java projects to ensure you don't have redundant 'catch' blocks
// for the old `com.palantir.remoting.api.errors.RemoteException` class.
// Old remoting-api jars are still allowed at runtime.

configurations.compileClasspath {
    resolutionStrategy.eachDependency { DependencyResolveDetails details ->
        if (details.requested.group == 'com.palantir.remoting-api' && details.requested.name == 'errors') {
            details.useTarget group: 'com.palantir.conjure.java.api', name: 'errors', version: dependencyRecommendations.getRecommendedVersion('com.palantir.conjure.java.api', 'errors')
            details.because 'Should not compile against RemoteExceptions from both http-remoting-api and conjure-java-runtime-api.'
        }
    }
}

This ensures that when you're migrating from http-remoting-api to conjure-java-runtime, your codebase is guaranteed not to catch the old exception anymore (com.palantir.remoting.api.errors.RemoteException), but the jars will still be present at runtime (which is important for other users)