Allow LDAP BindAuthenticator to skip attribute retrieval or retrieve using manager context

[alewando]

This patch adds a couple of properties (retrieveUserAttributes and retrieveAttributesWithManagerContext) that provide more control over how BindAuthenticator retrieves user attributes. If retrieveUserAttributes is set to false no user attributes will be retrieved and if retrieveAttributesWithManagerContext is set to true, the attributes are retrieved with the manager context (contextSource property) as opposed to the context obtained from the user bind.
I have seen SEC-1510 , and humbly ask that the 'Won't Fix' resolution be reconsidered. I have run in to multiple LDAP server configurations that throw errors when users attempt to access their own attributes, rendering the BindAuthenticator unusable even if you aren't interested in those attribute values at all. The suggested workaround on the jira issue (reimplement AuthenticationProvider) seems heavy-handed, throwing away the baby with the bathwater. I can understand the desire to keep the complexity down, but the way this patch is implemented preserves the default functionality (get user attribs, using the user context). Only someone who wanted to would need to set the additional properties. I think this situation is common enough in security-conscious enterprises that BindAuthenticator should at least allow configuration to prevent it from retrieving user attributes at all.

[rwinch]

As @tekul mentioned on SEC-1510 adding additional complexity to the existing classes is not desirable. The reason is that LDAP has too many permutations to support all scenarios (especially in a single class). Instead, you are encouraged to extend AbstractLdapAuthenticator and implement this yourself. For this reason this will be closed without being merged.