Test user::test::groups fails in devcontainer because real gid is not in supplementary groups

In a Visual Studio Code devcontainer based on Debian Bullseye the test user::test::groups fails.

Backtrace

$ RUST_BACKTRACE=1 cargo test -p fs-mistrust --lib
    Finished test [unoptimized + debuginfo] target(s) in 0.09s
     Running unittests (target/debug/deps/fs_mistrust-bf6b7cb33876b3a0)

running 26 tests
test err::test::bits ... ok
test test::default_mistrust ... ok
test user::test::lookup_id ... ok
test test::admin_only ... ok
test user::test::username_from_env ... ok
test user::test::selfnamed ... ok
test user::test::username_ignoring_env ... ok
test user::test::username_real ... ok
test test::multiple_errors ... ok
test test::check_contents ... ok
test test::trust_everyone ... ok
test test::want_type ... ok
test test::readable_ok ... ok
test dir::test::bad_paths ... ok
test dir::test::read_and_write ... ok
test test::trust_gid ... ok
test walk::test::past_root ... ok
test test::sticky ... ok
test dir::test::easy_case ... ok
test walk::test::simple_path ... ok
test walk::test::unix_permissions ... ok
test test::simple_cases ... ok
test test::make_directory ... ok
test walk::test::repeats ... ok
test walk::test::looping ... ok
test user::test::groups ... FAILED

failures:

---- user::test::groups stdout ----
thread 'user::test::groups' panicked at 'assertion failed: groups.contains(&cur_gid)', crates/fs-mistrust/src/user.rs:264:9
stack backtrace:
   0: rust_begin_unwind
             at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/panicking.rs:584:5
   1: core::panicking::panic_fmt
             at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/core/src/panicking.rs:143:14
   2: core::panicking::panic
             at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/core/src/panicking.rs:48:5
   3: fs_mistrust::user::test::groups
             at ./src/user.rs:264:9
   4: fs_mistrust::user::test::groups::{{closure}}
             at ./src/user.rs:256:5
   5: core::ops::function::FnOnce::call_once
             at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/core/src/ops/function.rs:227:5
   6: core::ops::function::FnOnce::call_once
             at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/core/src/ops/function.rs:227:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.


failures:
    user::test::groups

test result: FAILED. 25 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.03s

This appears to be due to cur_groups being vec![999] but cur_gid being 1000 and the test assumes that cur_gid will be in cur_groups. I'm not entirely sure why the container is set up this way, but it seems like it might be permitted by specification.

It is unspecified whether the effective group ID of the calling process is included in the returned list. (Thus, an application should also call getegid(2) and add or remove the resulting value.)

From https://man7.org/linux/man-pages/man2/getgroups.2.html

Here are some command outputs that seem relevant.

vscode ➜ /workspaces/arti (devcontainer) $ grep vscode /etc/group /etc/passwd
/etc/group:vscode:x:1000:
/etc/group:rustlang:x:999:vscode
/etc/passwd:vscode:x:1000:1000::/home/vscode:/bin/bash
vscode ➜ /workspaces/arti (devcontainer) $ ps -q $$ -eo pid,user,args,group,rgroup,supgrp 
  PID USER     COMMAND                     GROUP    RGROUP   SUPGRP
  252 vscode   /bin/bash                   vscode   vscode   rustlang
vscode ➜ /workspaces/arti (devcontainer) $ id
uid=1000(vscode) gid=1000(vscode) groups=1000(vscode),999(rustlang)