GH-3451: Use GreenMail for testing instead

Fixes https://github.com/spring-projects/spring-integration/issues/3451

The GreenMail provides a comprehensive support for e-mail scenarios
testing.

* Use GreenMail instead our own `TestMailServer` for better and broader
support
* Convert SmtpTests and Pop3Tests to GreenMail
* Document that Pop3MailReceiver does not support autoCloseFolder=false
* Pop3MailReceiver uses `folder.getMessageCount()` to determine if there
are new messages.
This count only gets updated when opening the folder.
* Use GreenMail for remaining mail tests
* convert MailTests and ImapMailReceiverTests to GreenMail
* remove duplicate mail dependencies
* route com.sun.mail logging to log4j (via jul and slf4j)

src/reference/asciidoc/mail.adoc

@@ -119,6 +119,7 @@ It now allows body-only rendering when a header mapper is provided.
 
 Starting with version 5.2, the `autoCloseFolder` option is provided on the mail receiver.
 Setting it to `false` doesn't close the folder automatically after a fetch, but instead an `IntegrationMessageHeaderAccessor.CLOSEABLE_RESOURCE` header (see <<./message.adoc#message-header-accessor,`MessageHeaderAccessor` API>> for more information) is populated into every message to producer from the channel adapter.
+This does not work with `Pop3MailReceiver` as it relies on opening and closing the folder to get new messages.
 It is the target application's responsibility to call the `close()` on this header whenever it is necessary in the downstream flow:
 
 ====

src/reference/asciidoc/testing.adoc

@@ -33,6 +33,7 @@ Examples of such tools include the following:
 * Gemfire and Hazelcast can be run as real-data grid nodes in the tests.
 * The Curator Framework provides a `TestingServer` for Zookeeper interaction.
 * Apache Kafka provides admin tools to embed a Kafka Broker in the tests.
+* The GreenMail is an open source, intuitive and easy-to-use test suite of email servers for testing purposes.
 
 Most of these tools and libraries are used in Spring Integration tests.
 Also, from the GitHub https://github.com/spring-projects/spring-integration[repository] (in the `test` directory of each module), you can discover ideas for how to build your own tests for integration solutions.
@@ -97,7 +98,7 @@ private UdpSyslogReceivingChannelAdapter adapter;
 
 @Autowired
 private PollableChannel sysLogs;
-...
+
 @Test
 public void testSimplestUdp() throws Exception {
     int port = TestUtils.getPropertyValue(adapter1, "udpAdapter.port", Integer.class);
@@ -145,7 +146,7 @@ PollerMetadata poller;
 
 @Autowired
 OnlyOnceTrigger testTrigger;
-...
+
 @Test
 @DirtiesContext
 public void testWithEntityClass() throws Exception {
@@ -363,7 +364,7 @@ assertEquals("FOO", receive.getPayload());
 Unlike the Mockito `MessageSource` mock object, the `MockMessageHandler` is a regular `AbstractMessageProducingHandler` extension with a chain API to stub handling for incoming messages.
 The `MockMessageHandler` provides `handleNext(Consumer<Message<?>>)` to specify a one-way stub for the next request message.
 It is used to mock message handlers that do not produce replies.
-`handleNextAndReply(Function<Message<?>, ?>)` is provided for performing the same stub logic for the next request message and producing a reply for it.
+The `handleNextAndReply(Function<Message<?>, ?>)` is provided for performing the same stub logic for the next request message and producing a reply for it.
 They can be chained to simulate any arbitrary request-reply scenarios for all expected request messages variants.
 These consumers and functions are applied to the incoming messages, one at a time from the stack, until the last, which is then used for all remaining messages.
 The behavior is similar to the Mockito `Answer` or `doReturn()` API.