The mapping from scancodes to the indexes used in xrdp_keymap
is not well designed and contains an implicit dependency on
keycode values.
This mapping is alse slightly different from the index used for
the 'keys' map in the xrdp_wm structure.
This commit introduces support for mapping scancodes directly
to 'scancode indexes' suitable for indexing into both structures.
Some renaming is also done; [MS-RDPBCGR] uses the terms scancode
and keyCode interchangeably. An effort is made to use key_code for a
raw value from a TS_KEYBOARD_EVENT, and scancode for a value which is
produced by the scancode module.
One of the tests uses a child process which generates SIGSEGV.
On FreeBSD this generates a corefile by default which breaks
the 'make distcheck' process.
The Debian build farm has a number of older and slower machines
which need to run the xrdp test suite.
On these platforms, we occasionally get timeouts where machine load is
high. This results in duplicate issues being raised. It is not obvious
that the issues are duplicates, which wastes time all round.
This commit splits up some test cases into multiple cases and
adds larger timeouts for those cases that are CPU-intensive.
Rename g_file_open() to g_file_open_rw(), and add a new g_file_open_ro()
call that wraps the common g_file_open_ex(file, 1, 0, 0, 0) idiom. This
will make the file access mode more explicit in the code.
Change all calls to g_file_open() to the _ro() or _rw() variant as
appropriate, and replace g_file_open_ex(file, 1, 0, 0, 0) with the _ro()
call.
Lastly, add tests for the two new calls to test_os_calls.c (code
courteously provided by matt335672).
Normally the test runners run in 'forking mode'. When a lot of
messages are logged to stdout, the child process can still be writing
data when the parent writes 'ok' or 'not ok'. This can confuse
the tap-driver.sh process.
