In recent Arch Linux builds we encountered some timeouts in tests.
Interestingly, the 30s timeouts were encountered not after 30s but
right-away. See the ctest output attached at the end of the message.

I remembered that Arch switched to glibc=2.33 recently. And by stracing
the test process I have noticed that indeed, the select in waitSignalTimeout
function timeouted early.
It seemed that the timeval struct is the problem and indeed it was. It
didn't like setting the 30s timeout as {.tv_sec = 0, .tv_usec = 30 *
1000 * 1000}. However, I can't find in any manpage why this is wrong...

It seems to be fixed by limiting tv_usec to be from [0; 1000*1000)
range and transfer the whole seconds into the tv_sec field.
And the glibc docs [1] says it so explicitely:

> When struct timeval values are produced by GNU C Library functions,
> the value in this field will always be greater than or equal to zero,
> and less than 1,000,000. When struct timeval values are supplied to GNU
> C Library functions, the value in this field must be in the same range.

[1] https://www.gnu.org/software/libc/manual/html_mono/libc.html#Time-Types

 -------------------------------------------------------------------------------
 aql/AutomatonIteration.aql
 -------------------------------------------------------------------------------
 /builds/algorithms-library-toolkit/infrastructure/cd-release/src/algorithms-library-snapshot/build/tests/AutomatonIteration.cpp:17
 ...............................................................................

 /builds/algorithms-library-toolkit/infrastructure/cd-release/src/algorithms-library-snapshot/tests/testing/TimeoutAqlTest.cpp:206: warning:
   AqlTest: timeout (30000000 us) reached
   Trying to execute testfile /builds/algorithms-library-toolkit/infrastructure/cd-release/src/algorithms-library-snapshot/tests/aql/AutomatonIteration.aql

 Seed was: 1053288110
   Child aqlout was: ><
   Child stdout was: ><
   Child stderr was: ><

 /builds/algorithms-library-toolkit/infrastructure/cd-release/src/algorithms-library-snapshot/tests/testing/TimeoutAqlTest.cpp:208: FAILED:

 ===============================================================================
 test cases: 1 | 1 failed
 assertions: 3 | 2 passed | 1 failed

Start working on custom code-style/code-requirements file checker.
So far we check only for missing license, for non-standard EOL (\r) and
for files that not-compliant with clang-format.

... because most developers were copy-pasting the preambule anyway and
did not pay any attention to change it.

Also, I think that git does better job in managing that.

The parents were set incorrectly in swap of trees and tries. Parents in children
of swapped objects should be set, not the parents in swapped objects.

The template function sort internally called swap so it internaly tests
swap of trees

Take out common code in then and else branch

The case (b*+a)* was only optimized to (b+a)* by lemma V4.

This test generates a random automaton, runs both iteration algorithms on
it and then tests that both these automata accept equal language.

This is first of the aql integration tests (which support was added in
commit d79fe028). This should serve as
an example how to write aql integration tests.
Also, this is something that should not be in the unit tests (and it
was removed in the previous commits).

Algorithm automaton::transform::AutomatonIteration resulted in wrong
output when the input automaton had a transition from the initial state to a
final state.
If such transitions exists, we must also add a transition from the new
initial state to the old initial state in the new automata.

Added a test case for this particular case.

Closes #211

The tests for iteration were "messy". It was not clear what are they
doing and also we tested two algorithms in one test case.

Split those algorithms and make them clear -- test only for expected
output.

There were two instances of the AutomatonIteration::iteration method,
one for working with DFAs, one for NFAs. However, both shared the same
code.
Let's merge those methods.

protected field break encapsulation

it was replaced with a constraint

methods ext::Variant < ... >::set are joined + refactored to fix the std::move
vs std::forward issue

concepts are language native construct that was introduced to replace enable_if
(SFINAE)

moving is actually more expensive for shared_ptrs

constructor accepting an universal reference may interfere with move constructor

add const qualification, remove explicit initialization of string to empty, and
unify parameter names between declaration and definition

primitive types don't need std::move

remove unnecessary move of an integral value, add const qualifier to a method
that does not change the this object and remove another use of _identifier