fix(element-finder): handle element not found errors correctly #4079

[Conqxeror]

This commit addresses several issues related to handling element not found errors in the element finder utility.

Issues Fixed #4079 :

• Replace TimeoutError with NoSuchElementError when an element is not found.
• Return null instead of throwing an error when an element is not found.
• Abort the test case when abortOnFailure is set to true and an element is not found.
• Update error messaging to provide more specific information when an element is not found.

Changes:

• In the findElement method, a NoSuchElementError is created and registered with the reporter when an element is not found. The method now returns null instead of throwing an error.
• In the findElementAction method, null is returned when an element is not found and suppressNotFoundErrors is true. If abortOnFailure is true and an element is not found, the corresponding error is thrown to abort the test case.
• The createNarrowedError function has been updated to create a more specific error message for NoSuchElementError.
• Updated the test cases to verify the correct error handling and test case abortion scenarios.
• Updated the configuration file (nightwatch.json) to set the abortOnFailure option for all test cases.

These changes improve the reliability and maintainability of the element finder utility by providing better error handling, error messaging, and behavior when dealing with scenarios where an element is not found.

Thanks in advance for your contribution. Please follow the below steps in submitting a pull request, as it will help us with reviewing it quicker.

• Create a new branch from master (e.g. features/my-new-feature or issue/123-my-bugfix);
• If you're fixing a bug also create an issue if one doesn't exist yet;
• If it's a new feature explain why do you think it's necessary. Please check with the maintainers beforehand to make sure it is something that we will accept. Usually we only accept new features if we feel that they will benefit the entire community;
• Please avoid sending PRs which contain drastic or low level changes. If you are certain that the changes are needed, please discuss them beforehand and indicate what the impact will be;
• If your change is based on existing functionality please consider refactoring first. Pull requests that duplicate code will most likely be ignored;
• Do not include changes that are not related to the issue at hand;
• Follow the same coding style with regards to spaces, semicolons, variable naming etc.;
• Always add unit tests - PRs without tests are most of the times ignored.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}