Create more robust solution for file executable permissions check

[richtja]

Is your feature request related to a problem? Please describe. In issue #5945 and related PR #5946 we have discovered that os.access is not that robust as we thought and can provide false resolutions in specific environment.

Here is more information related to this topic provided by @eeslook:

1. Python Official Documentation:

   • os.stat()
   • os.access()

2. Security Considerations in Python Official Documentation:

   • Security considerations mention the security considerations of os.access:

     Note I/O operations may fail even when access() indicates that they would succeed, particularly for operations on network filesystems which may have permissions semantics beyond the usual POSIX permission-bit model.

3. Linux Manual Pages:

   • access(2) - Linux manual page

     access() checks whether the calling process can access the file pathname. If pathname is a symbolic link, it is dereferenced.
     
     The check is done using the calling process's real UID and GID, rather than the effective IDs as is done when actually attempting an operation (e.g., open(2)) on the file.
     
     This allows set-user-ID programs and capability-endowed programs to easily determine the invoking user's authority.  In other words, access() does not answer the "can I read/write/execute this file?" question.  It answers a slightly different question:"(assuming I'm a setuid binary) can the user who invoked me read/write/execute this file?", which gives set-user-ID programs the possibility to prevent malicious users from causing them to read files which users shouldn't be able to read.
     
     If the calling process is privileged (i.e., its real UID is zero), then an X_OK check is successful for a regular file if execute permission is enabled for any of the file owner, group, or other.

4. Secure Programming Practices:

   • Secure Programming for Linux and Unix HOWTO
     • This document discusses many best practices for secure programming, including avoiding the use of access() for permission checks to prevent race conditions and privilege escalation attacks.

Describe the solution you'd like Because we use os.access in the crucial part of avocado, we need to make sure that it is stable and secure. Let's create a utility based on the solution from #5946 which can replace occurrences of os.access from Avocado code.