Fix of LDAP URL parsing and querying attributes.

Created by: andrejrupar

The current CommonsDataLoader implementation does not work with some LDAP CRL distribution points of some Slovenian CA-s. Examples of such URL-s taken from production certificates are: 1. ldap://x500.gov.si/ou=sigen-ca,o=state-institutions,c=si?certificateRevocationList?base 2. ldap://postarca.posta.si/ou=POSTArCA,o=POSTA,c=SI?certificateRevocationList 3. ldap://acldap.nlb.si/o=ACNLB,c=SI?certificateRevocationList

This is caused by the following two reasons: A. LDAP URL-s assume the following structure: ldap://host:port/DN?attributes?scope?filter?extensions (see https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol). The current CommonsDataLoader.ldapGet implementation obtains attributes as the part of URL after the last '?' character, which is a bug. It fails on URL 1. above. B. Attribute names in the above URL-s do not exactly match the actual attributes on the server, which also contain a "binary" option. This is the case in all of the above examples.

Issue A. is resolved by parsing attributes as the substring after the first occurence of '?' and before the (optional) second. For issue B. the method is improved by querying the server just for the specific attributes, which are obtained from the URL. In this way differerent attribute names are handled by the LDAP server instead of the client.