Rework LdapClient to Align with JdbcClient API

[therepanic]

This commit added the single, optional, list, and stream methods to the LdapClient#SearchSpec and deprecated the implementations that will be deprecated by this change.

Please note that this is a WIP: I have a couple of comments that would be helpful to address.

Closes: gh-1404

[jzheaux]

Looking good so far, @therepanic! If you feel good about it, let's go ahead and proceed with testing and with updating the documentation.

[therepanic]

Are there any other concerns other than the duplication?

I believe we can't simply hide the same logic in toMap, toObject, and toStream methods as in DefaultLdapClient, since it relies on some local variables. For example, toList in DefaultLdapClient internally uses computeWithReadOnlyContext, which in turn uses contextSource, and so on.

What default implementation would we like to see for these methods?

[jzheaux]

I see, @therepanic. Have you considered creating DefaultMappedSearchSpec inside of DefaultLdapClient?

[jzheaux]

Hi, @therepanic, does my last comment help you find a direction to take the PR? I can also push a commit that you can work into the PR as you see fit, in case that helps.

[jzheaux]

@therepanic, I went ahead and pushed a suggestion along with updates to documentation and tests. I propose that we throw an UnsupportedOperationException in map since, without the state of the SearchSpec implementation, map cannot successfully return a new builder object.

Do you have any concerns with this approach? I'm confident enough in it that I'll merge it later this week if I don't hear from you, so don't feel obligated to respond. 👍

[therepanic]

Hi, @jzheaux. I'm really sorry, I had some issues that kept me from figuring this out. I took a look at your changes in polish commit and I think this is exactly what's needed. You've also updated the documentation and tests, so I think it looks ready for merge.

After the merge and version update, we'll be able to update the implementation directly in all projects that use this API. Specifically, I've decided to monitor this issue within Spring Security itself, which is where the idea for these changes came from.

[jzheaux]

@therepanic, it's not a problem at all. I found some time this week and that increased the changes of this going into 4.1, so it's a win-win.