Add NixOS to the approved OS page

Why is this change being made?

This MR refers to the Linux Distribution NixOS

The purely functional package manager Nix, allows us to specify completely reproducible and powerful development environments, this has some similarities with tools like asdf, but much more powerful ( eg, subdependencies ).

NixOS takes this a step further to the OS level, allowing a user to describe their entire system from a simple configuration file, this includes users, mount points, kernel versions and more. In turn this makes configuring and auditing packages, OS upgrades etc an absolute dream. see this for the full scope of what we'd stand to lose.

This change is being made to update the existing list of supported operating systems. In particular, adding NixOS 22.11 to the list of supported systems.

After testing, I was able to get both SentinelOne and DriveStrike deployed and working correctly in a reproducible way;
I think that this justifies allowing the tested version to be added to the list.

A list of concerns raised from various sources (and how I think they should be addressed):

• In this comment we learned of the list of kernel criteria.
  • NixOS is able to declaratively set it's kernel to a supported version.
• Neither DriveStrike or SentinelOne technically support NixOS, so there's a real possibility that it might malfunction, or stop working altogether in a future update.
  • We've confirmed that these tools work correctly on NixOS 22.11, 23.05; Although given nix's nature barring a wonky kernel update the environment should be consistent across versions.
  • NixOS allows us to test changes to our OS before applying them, so we'll know in advance if an update could potentially break them - it also features a boot-level rollback mechanism, so in the event that an update to either SentinelOne or Drivestrike, we have a sophisticated mechanism to boot back into a compliant system immediately.
  • If it turns out that an update does indeed break the functionality of either of these two tools on NixOS, due to the aforementioned testing and rollback capabilities, NixOS machines can still stay compliant while its either fixed or while the user has time to migrate to another distro

Summarized discussions from the linux slack channel:

@WarheadsSE: Who is going to regularly maintain and test this?
@WarheadsSE: Is there anyone else in the team that has the ability to do this work as well? How can we ensure coordination of that?
@WarheadsSE: How do we verify compliance?
@WarheadsSE: How to fully vet that SentinelOne / DriveStrike are operating as intended?

@knottos: Ive been maintaining a gitlab.nix of all the SRE level dependencies here, which ill just link into my configuration with
imports = 
    [ 
      ./gitlab.nix
    ];

@knottos: so id imagine to create (in a repo somewhere) a compliance.nix, which we can import in the same way
@knottos: Im not aware of anyone else who uses NixOS, but then I only did just discover this channel today
@knottos: In these threads @ericrubin @plaurinavicius checked that its registered correctly in the dashboards (for this particular case)

https://gitlab.slack.com/archives/C043PF9TU4X/p1675377923814089?thread_ts=1675377863.713759&cid=C043PF9TU4X
https://gitlab.slack.com/archives/CK4EQH50E/p1675426113636149?thread_ts=1675422998.261679&cid=CK4EQH50E

In the case of sentinelone, we can check by the given command in the handbook, and we can check the numerous log files it outputs
for drivestrike, there doesnt appear to be any local 'does it work' commands, apart from systemctl status; 

Operating as intended though? I mean we'd need to know exactly what it _does_ first I think.
  
@knottos: 
Im interested in the answer to that too, Id need an example of how we verify compliance on Ubuntu/Fedora etc to be able to say accurately

Author Checklist

• Provided a concise title for this Merge Request (MR)
• Added a description to this MR explaining the reasons for the proposed change, per say why, not just what
  • Copy/paste the Slack conversation to document it for later, or upload screenshots. Verify that no confidential data is added, and the content is SAFE
• Assign reviewers for this MR to the correct Directly Responsible Individual/s (DRI)
  • If the DRI for the page/s being updated isn’t immediately clear, then assign it to one of the people listed in the Maintained by section on the page being edited
  • If your manager does not have merge rights, please ask someone to merge it AFTER it has been approved by your manager in #mr-buddies
  • The when to get approval handbook section explains the workflow in more detail
• If the changes affect team members, or warrant an announcement in another way, please consider posting an update in #whats-happening-at-gitlab linking to this MR
  • If this is a change that directly impacts the majority of global team members, it should be a candidate for #company-fyi. Please work with internal communications and check the handbook for examples.

---