Fix UAM challenge race by issuing challenges in the main daemon

[gmarsay]

Summary

Parallel chilliredir workers could each generate a different UAM challenge while the main daemon still had uamtime == 0 (or before state was synchronized). The HTTP response seen by the client could then disagree with the challenge stored in chilli, leading to valid credentials but RADIUS Access-Reject (especially with CHAP). A retry often worked because a single code path then owned the session.

In my case, this represents approximately 5 to 10% of login attempts that result in an "Access-Reject".

The behavior seems to be related to the type of device being used; it is consistently reproducible with a Google Pixel 7a but not with an iPad, for example.

Solution

Challenge creation / refresh for the affected UAM paths is moved to the main chilli daemon, which already handles UAM IPC in a single-threaded way for each accepted connection. The redir side uses a new Unix-socket RPC (same pattern as REDIR_MSG_STATUS_TYPE / redir_conn_t reply): message types 1001–1004 encode the same policy as the previous redir_memcopy(REDIR_CHALLENGE) sites (prelogin/splash, status, challengetimeout2, and “always” on reject when challengetimeout is set).

Random bytes are read in the daemon via a small helper uam_random_challenge() in util.c (shared with the former redir-side /dev/urandom logic).

[gmarsay]

After a week of activity on an instance, with over 6000 connections, there are no more errors.

@sevan : Do you see anything problematic with this PR ?

[sevan]

Meged, thanks.