feat: withAndWithoutLongTermEnabled mod implementation

[vtronkov]

Description:

1. Converting defaultHapiSpec to hapiTest*
2. Implementing AllTestsWithLongTermFlagEnabledTest and AllLeakyTestsWithLongTermFlagEnabledTest that consist of ALL_TEST list of test classes. In these new test classes we are getting all tests methods from ALL_TEST, we enable the scheduling.longTermEnabled flag and run the tests. That way we are not having a separate CI step and we are testing the scheduled tests with the flag enabled**
3. Ignoring signFailsDueToDeletedExpiration test since it works only with longTermEnabled=false

• *This was relevant for the first implementation but not anymore. I will leave the change because we are using hapiTest more frequently.
• **I separated the tests to @HapiTests and @LeakyHapiTests because the leaky tests are running in series. In order to make it work I need to annotate runAllTests with @LeakyHapiTest which makes all ~110 tests running in series because of 5 tests that are leaky. If I combine all the tests it takes about 1:20 minutes(as embedded test) to run all tests. If they are separated it takes around 30 seconds.

Related issue(s):

Fixes #16010

Checklist

• Documented (Code comments, README, etc.)
• Tested (unit, integration, etc.)

The history of the different implementations

(just for reference/history, not required to read)

1. My first idea was to make it work as _Eth suffix is working but this wasn't exactly how the mono's withAndWithoutLongTermEnabled was working. So I put it aside.
2. Writing a jUnit extension to turn on the flag - I was unable to figure out a way to insert SpecOperation into the currently executed method. I didn't spend too much time here because I didn't quite like this solution
3. Wrote my own HapiSpec.hapiTest method
   3.1 In The first version I was building two separate DynamicTest - one with the flag turned on and one with the flag turned off. Then I put the two tests into the returned Stream<DynamicTest>. This was kinda working but I had problems with the state and things didn't work the way I expected.
   3.2 In the second version I was building a single DynamicTest where I put the operation twice - with a flag operation turned off at the beginning and a flag operation turned on between the tests. Again I had some store problems, the ids were duplicated and I got errors along the lines of "the scheduled transaction was already executed". I tried fixing these problems by changing the names of the operations but in order to do that I had to make deep copies of the objects and it was getting more complicated than needed.
4. In the end, I returned to the original idea - using the file name as an indicator that the flag should be turned on(and eventually adding additional logic).
5. Because of the discussion with Michael(see below) and since we decided not to add the additional complex logic there is no need to implement the suffix solution. Thus the AllTestsWithLongTermFlagEnabledTest and AllLeakyTestsWithLongTermFlagEnabledTest was implemented(see details above)

My questions to @tinker-michaelj are:

1. Are you okay with this approach or you had something else in mind? If so I'm guessing I will try to integrate this with CI just like _Eth was working
2. Currently all tests from the schedule package instead of 2 are passing. In the beginning, we were talking about making this logic smart so it can detect that the flag is turned on and if needed to sleep until a scheduled transaction is executed. It looks like most of the tests are testing the transactions themselves and there are only a few end-to-end tests where this additional logic will be helpful. Maybe it's an overkill to add it at that point and it would be easier to write tests that are only for long-term transactions. Or maybe I'm missing something here?

Discussed this with Michael - we don't need the additional "understanding that the flag is on and make the test sleep until the transaction is executed" is not needed because the tests are not written in that way

[tinker-michaelj]

Nicely executed @vtronkov ! LGTM, tyvm 🙏