New fix flaky

[akib6075]

Fixes #ISSUSE_ID
JSONUtil.toJSONString() which is coming from JacksonHandler returning unordered object which fails in test.
So I changed the testcase as well.
Please have a look.
Flaky test evidence using the NonDex tool: https://github.com/akib6075/hippo4j/actions/runs/4519255268
after resolving flaky test evidence using the NonDex tool: https://github.com/akib6075/hippo4j/actions/runs/4519274552
Changes proposed in this pull request:

Check mailbox configuration when submitting. Contributor Guide

[weihubeats]

Please resolve conflicts

[akib6075]

@weihubeats there is a loophole in the assertGetPoolContent() which is the testText is a collection of threadpoolparameter info which has a specific order of the keys. But the ContentUtil.getPoolContent() returns the threadpoolparameter info having different order of keys. So it's happening because of different order of keys in the Json serialization.
This is failed CI log: https://github.com/akib6075/hippo4j/actions/runs/5135847635

To fix this I made a solution which serializes and deserializes to check that the object is the same. Now the question can come that my solution uses ContentUtil.getPoolContent() twice. So the result must throw error again. But the answer is no. Because the caching of properties is implemented in the databind module's internal classes, such as com.fasterxml.jackson.databind.introspect.POJOPropertiesCollector and com.fasterxml.jackson.databind.introspect.POJOPropertyBuilder. These classes are responsible for inspecting the structure of Java classes and extracting their properties.
Jackson utilizes a caching mechanism for property introspection, which involves caching the metadata associated with Java classes to improve performance during serialization and deserialization. This caching is performed by the Jackson databind module, which is typically used in conjunction with the ObjectMapper.
JacksonHandler.java used this library by importing com.fasterxml.jackson.databind.*;
The fixed CI log: https://github.com/akib6075/hippo4j/actions/runs/5190631210

[weihubeats]

You can mention an issue in the issues list, and then associate it here, see this pr: #1380

[weihubeats]

Why do you have so many file changes? I feel like there should be something wrong with your code merge? Wouldn't it be a good idea to consider pulling a new branch from the latest branch and re-committing your code

[akib6075]

@weihubeats Thank you for your feedback. I understand your concern about the large number of file changes. I've reviewed the commits and believe they are necessary to address the flaky tests issue. However, I'm open to discussing alternative approaches. Would you like me to provide more details about the changes or would you prefer I rebase the branch and submit a new merge request? Also I've opened same PR which is #1373. You can check that as well.