Add ctest for different hadoop-common tests

[nikhil96sher]

Test 1 - org.apache.hadoop.security.ssl.TestSSLFactory#testServerWeakCiphers.

1. hadoop.ssl.enabled.protocols - Based on the following link: https://risdenk.github.io/2018/11/15/apache-hadoop-tls-ssl-notes.html, Java 7+ should support TLSv1, TLSv1.1, TLSv1.2. Default Value: TLSv1.2.
2. hadoop.ssl.keystores.factory.class - Default Value: org.apache.hadoop.security.ssl.FileBasedKeyStoresFactory
3. hadoop.security.credential.clear-text-fallback - Default Value: True
4. hadoop.security.credential.provider.path - Default Value: Empty.

Test 2 - org.apache.hadoop.crypto.TestCryptoStreamsWithJceAesCtrCryptoCodec#testRead

1. hadoop.security.crypto.cipher.suite - Default Value: AES/CTR/NoPadding.
2. hadoop.security.java.secure.random.algorithm - Default Value: SHA1PRNG. The available PRNG algorithms in JCE provider are MD5PRNG and SHA1PRNG. But, the above test also passes when you instead use simple hashing algorithms like MD5.
3. hadoop.security.crypto.jce.provider - Default Value: Empty.

Test 3 - org.apache.hadoop.io.erasurecode.coder.TestRSErasureCoder#testCodingBothBuffers_10x4_erasing_d0_p0

1. io.erasurecode.codec.rs.rawcoders - Default Value: rs_native,rs_java. The property doesn't specify that it requires atleast two valid rs coders. The test function expects that there are atleast two available rs coders. Hence, rs_native - although a valid value according to the property definition leads to the test failing. A check on the number of available raw coders can be included before the test to make sure the test is only run when more than one coder are specified. Interesting scenario is one where you have multiple coders - with only two of them valid and the test is able to pass as two valid coders are available.

Test 4 - org.apache.hadoop.security.authorize.TestAccessControlList#testAclString

1. hadoop.security.group.mapping - The mapping service to be used to obtain user-group mapping. Default Value: JniBasedUnixGroupsMappingWithFallback. There are other additional values - JniBasedUnixGroupsMapping, ShellBasedUnixGroupsMapping which are valid group mapping classes. JniBasedUnixGroupsMapping doesn't work because JNI is not available on the system. In case of default value, it falls back to ShellBasedUnixGroupsMapping and hence works correctly.
2. hadoop.security.groups.cache.background.reload - True/False.
3. hadoop.user.group.static.mapping.overrides - Override for the user-group mapping. Tried semantically invalid user-group mapping strings and the tests still pass.

Test 5 - org.apache.hadoop.security.TestUserGroupInformation#testGetServerSideGroups

1. hadoop.security.group.mapping - The mapping service to be used. The behavior is similar to the parameter behavior in the above test.
2. hadoop.user.group.static.mapping.overrides - The given test uses the currently logged-in user and obtains the actual groups the user belongs to. An interesting way to override this is with $(whoami)=only_one_group. Now, with the overridden mapping the test should have passed since it is a valid input value. But the test fails as it still relies on the underlying group membership.
3. hadoop.security.authentication - Default Value: simple. Also tried: kerberos.

Note: For tests that rely on underlying system's information to obtain information, having ctests with values which are the result of bash commands is an interesting way to increase the scope of ctests.

[nikhil96sher]

@Alex-Lian Could you review this PR?

[xylian86]

@nikhil96sher Looks good to me.

[tianyin]

@Alex-Lian

Looks good to me.

say LGTM :)

[xylian86]

@tianyin Got it!