HDDS-7440. Delete package-info class for org.apache.hadoop.io.erasurecode.rawcoder to avoid conflict with Hadoop

[adoroszlai]

What changes were proposed in this pull request?

Trying to use Ozone FS jar in Spark points out conflict with one of Hadoop's packages:

scala> :require /opt/ozone/share/ozone/lib/ozone-filesystem-hadoop3-1.3.0-SNAPSHOT.jar
The path '/opt/ozone/share/ozone/lib/ozone-filesystem-hadoop3-1.3.0-SNAPSHOT.jar' cannot be loaded, it contains a classfile that already exists on the classpath: org.apache.hadoop.io.erasurecode.rawcoder.package-info

https://issues.apache.org/jira/browse/HDDS-7440

How was this patch tested?

Regular CI:
https://github.com/adoroszlai/hadoop-ozone/actions/runs/3368073737

After the update Spark still complains, but only about non-shaded third-party classes. Those will be addressed in separate task.

[myskov]

BTW what about dropping JavadocPackage rule? I believe it's adopted from Hadoop code style, but it doesn't seem to make much sense.

[myskov]

Dropping the rule will allow to remove useless (in most cases) package-info files.

[kerneltime]

@adoroszlai would shading be a better approach as we might not want EC package to be picked by the application but be based on the actual testing done in the released version?

[adoroszlai]

would shading be a better approach?

I don't think shading helps here. We need this Hadoop-specific package name to access some protected members in some Hadoop classes in the same package. The only real code in this package is the utility to access the Hadoop code. If we shade the Ozone's classes in this package then I don't think it will be able to access Hadoop classes. If we shade both Hadoop and Ozone, we're back to duplicate package-info class.

The other possible solution is to copy all related code from Hadoop, but I think the goal in this case was to avoid that.

[adoroszlai]

Thanks @kerneltime, @myskov, @sodonnel for the review.