TL,DR: you probably want /proc/PID/loginuid, even though its behavior doesn't always match logname. But it doesn't work out of the box on all distributions. Note that my answer assumes Linux, it does not apply to other Unix variants.
I don't think you'll find a fully satisfactory answer because you don't have clear expectations from what logname does. On the one hand, you're currently using logname, which is based on utmp records — records that associate a user with a terminal, and which are updated at the good will of the terminal emulator (many don't). On the other hand, you expect that “the possibility to change the username should be limited to the superuser”. This is not the case with utmp records! As explained in the very comment thread you cite, utmp records work most of the time, but they can be faked.
Defining “the username that was used to log into the console” is problematic. It's clear enough in nominal cases, but there are many complicated cases. What happens if a user calls su and attaches to another user's screen session? What happens if a user attaches to another user's X11 or VNC session? How do you trace processes to terminals — what do you do about processes that have no controlling terminal?
Linux actually does have a concept of “login UID”. It's visible for each process as /proc/PID/loginuid. This information is tracked by the kernel, but it's up to userland to let the kernel know when a login takes place. This is normally done via pam_loginuid. Under the hood it's done by writing to /proc/self/loginuid. Linux's login UID follows process ancestry, which is not always the right definition but has the benefit of being simple.
Beware that if a process's login UID is 4294967295 then the process may change it. Init starts with the login UID 4294967295 (equal to -1 as a 32-bit value); this normally indicates a process that's not part of any login session. As long as the login process sets the login UID correctly (just before it sets the real UID from root to the user who's logging in), that's fine. But if there's a way to log in without the login UID set then the user may declare any login UID of their choice. So this information is reliable only if all the ways to run a process on the system go through a step of setting the login UID — forget one and the information becomes useless.
Experimentally, on a Debian jessie machine, all my long-running processes whose login UID is -1 are system services. But there are ways to run a process with login UID of -1, for example via incron. I don't know how many other ways there are; incron was the first I tried and it worked. On Ubuntu 16.04 machine, the pam_loginuid entry for lightdm is commented out, I haven't investigated why. Maybe Ubuntu's lightdm and incron should be considered security bugs, but the fact is that today you can't rely on the login UID working out of the box in major distributions.
See also Loginuid, should be allowed to change or not (mutable or not)?, which is about a kernel option to prevent root from changing the login UID. But beware that it's only effective after the login UID has been set to a proper value; if a user gets to run a process with the login UID still set to -1 then they can set it to whatever they want. It would in fact be safer to make init switch to a different value, say -2, and have pam_loginuid override that value; then -1 would never happen and -2 would indicate “unknown”.
