Runtime initialization fails for debug builds configured with static NIFs

[lexprfuncall]

Describe the bug

Calls to erts_add_taint check invariants that are not established when called by static_nif_init.

To Reproduce

First, build Erlang/OTP with one or more static NIFs. This script should work

#!/bin/sh
export ERL_TOP=`pwd`
ASN1_NIF_PATH=$ERL_TOP/lib/asn1/priv/lib/x86_64-pc-linux-gnu/asn1rt_nif.a
CRYPTO_NIF_PATH=$ERL_TOP/lib/crypto/priv/lib/x86_64-pc-linux-gnu/crypto.a
./configure \
    --enable-static-drivers \
    --enable-static-nifs="$ASN1_NIF_PATH, $CRYPTO_NIF_PATH" \
    --without-javac \
    --without-jinterface \
    --without-odbc \
    LIBS="-Wl,--as-needed -lcrypto -Wl,--no-as-needed"
make -j
(cd $ERL_TOP/erts/emulator && make -j debug)

Next, then run the debug build. Here is what I see on my Linux systems

$ ./bin/erl -emu_type debug
beam/erl_nif.c:4440: Lock check assertion "erts_lc_rwmtx_is_rwlocked(&erts_driver_list_lock) || erts_has_code_mod_permission()" failed!
Currently no locks are locked by the unknown thread.
zsh: IOT instruction (core dumped)  ./bin/erl -emu_type debug
$

Expected behavior

The runtime should start normally.

Affected versions

I am running maint but, from the git history, it seems like this might be a few years old.

Additional context

An assertion is tripped by erts_add_taint which is transitively called by erl_init without

1. erts_driver_list_lock being locked
2. and, since erts_start_schedulers has not yet been called, erts_has_code_mod_permission will always return false

From the commit history, it looks like tracking taint information for static NIFs was deliberate. However, it looks as if the invariants checked by erts_add_taint might not be relevant to static_nifs_init since

1. there is no interaction with the driver list that is protected by the aforementioned lock
2. and the call occurs too early for any interaction with the scheduler and the creation of values for the sched_data_key TLS key

Since there are no other calls to erts_add_taint at initialization time, checking !erts_initialized in the assertion seems to be sufficient to make the error go away without affecting any post-initialization calls to erts_add_taint.