This bug was introduced by OTP-13388.

test_server:start_node does no longer add the test_server path to the
new node, since the needed code is present in the default path. This
caused two test cases in code_SUITE to fail.

code_SUITE:mult_lib_roots: Expected the test_server path to be first
in the code path. This check is removed.

code_SUITE:bad_erl_libs: Started a node with "-env ERL_LIBS ",
i.e. not giving any value to the ERL_LIBS variable. This test
succeeded by accident, since the combination with arguments set by
test_server_node.erl and by slave.erl caused the node start to work,
and no further checks were present in the test. This part of the test
case is now removed.

Change scheduler responsiveness to 'check_schedulers'.

* rickard/monotonic-time-improvements/OTP-13222:
  Introduce time management in native APIs
  Introduce time warp safe replacement for safe_fixed option
  Introduce time warp safe trace timestamp formats

The specifications for functions that load code in the 'code'
module (e.g. code:load_file/1) have some problems:

* The specs claim that the functions can return {error,on_load}, but
  they never do. However, they can return {error,on_load_failure} if
  the -on_load function in a module fails.

* The specs claim that the functions can return {error,native_code},
  but they never do.

While we are it, also extend the on_load_errors/1 test case to test
that the load functions return {error,on_load_failure} when an
-on_load function fails.

The run-time system would terminate if code:load_abs/1 was
called with a filename containing any non-latin1 characters.
The reason is that code_server would attempt to construct a
module name from the filename using list_to_atom/1 and that
atoms currently are limited to the latin1 character set.

But how should the error be reported?

I have decided to that the simplest and least confusing way
is to move the call to list_to_atom/1 to 'code' module and
let it crash the calling process. The resulting stack back
trace will make it clear what the reason for the crash was.

New timestamp options for trace, sequential trace, and
system profile:
- monotonic_timestamp
- strict_monotonic_timestamp