Secret Driver for Community Implementation.

Description:

Link to ADR: https://gitlab.opengroup.org/osdu/pmc/community-implementation/-/issues/22
More details about the solution: https://community.opengroup.org/osdu/documentation/-/wikis/Pluggable-approach-for-Mappers-and-Drivers

• Added Maven shade plugin, which allows to build uber JAR with required dependencies, and shade them to avoid classpath conflicts.
• Removed redundant dependencies. Driver shouldn't have redundant dependencies, it complicates uber JAR build.
• Move dependencies to module pom files, to not force consumers to download redundant ones.
• Module and artifact ID renamed according to convention.
• Implement secret driver for Kubernetes Secret Manager.
• Added a core part to implement new drivers.

Key components of pluggable configuration:

1. Maven shade plugin, used to compile uber jar, with unique dependencies onboard:

            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-shade-plugin</artifactId>

2. Important parts of the maven shade plugin configuration:
   

• We do not need to deploy the reduced by maven shade POM file into the registry, to keep the ability to use the original jar file as is.
• The plugin jar will be deployed to the registry in addition to the original jar.
• The plugin jar will be classified, making it possible to use :classifier in other maven tasks.
• Signature files should be excluded from dependencies.

                        <configuration>
                            <!-- do not deploy reduced pom --> 
                            <createDependencyReducedPom>false</createDependencyReducedPom>
                            <!-- deploy plugin jar --> 
                            <shadedArtifactAttached>true</shadedArtifactAttached>
                            <!-- use the classifier to distinct plugin jar and original jar -->
                            <shadedClassifierName>plugin</shadedClassifierName> 
                            <!-- filter out signatures from signed jars, to prevent SecurityException -->
                            <filters>
                                <filter>
                                    <artifact>*:*</artifact>
                                    <excludes>
                                        <exclude>META-INF/*.SF</exclude>
                                        <exclude>META-INF/*.DSA</exclude>
                                        <exclude>META-INF/*.RSA</exclude>

Driver usage from a service perspective:

Changes include:

• Refactor (a non-breaking change that improves code maintainability).
• Bugfix (a non-breaking change that solves an issue).
• New feature (a non-breaking change that adds functionality).
• Breaking change (a change that is not backward-compatible and/or changes current functionality).

Changes in:

• Community Implementation

Dev Checklist:

• Added Unit Tests, wherever applicable.
• Updated the Readme, if applicable.
• Existing Tests pass
• Verified functionality locally
• Self Reviewed my code for formatting and complex business logic.

Other comments:

Two major requirements should be considered when the Driver is built as a Plugin:

1. Driver JAR should contain all required dependencies a.k.a UBER JAR. Since Maven won't be help to download all transitive dependencies of Driver JAR, we should combine them at the compile step.
2. Driver JAR should minimize them to only unique dependencies. For example, osdu-core-common.jar should not be part of it, but MinIO.jar should. This will help to avoid classpath conflicts.