Document support (or lack thereof) of libmi

[TravisEz13]

Summary of the new document or enhancement

Details of requested document:

• Proposed title:
• Propose location in the TOC:
• Target audience: WinRM remoting using on Linux and macOS
• Purpose or scenario:
• List of related articles to link to:

OMI (libmi.so or libmi.dylib) cannot be support for the following reasons:

1. OMI will not fix PowerShell bugs meaning PowerShell cannot offer any level of support

   PowerShell is out of omi scope now.

   • Known and unknown security issues will not be fixed
     • Know security issues are mitigated with warning in the PowerShell code
2. OMI does not load OpenSSL correctly causing segfaults
   Here you can see that OMI has the expectation that OpenSSL is carried around with the package.
   This is a different expectation than .NET leading to segfaults when conflicting depenecies are loaded.

[sdwheeler]

@TravisEz13 Is this a replacement for or an extension of #5437?

[TravisEz13]

I guess more of an extension, but I think independent of #5437
This is more to document the reasons in general that we can't address the issues.
#5437 is to document where in the Linux distribution lifecycle it's failing.

[SteveL-MSFT]

I'm not sure what we want to document here. The libmi situation is unfortunate, but there has been some community work for an updated version of libmi, but it's not something our team supports.

[sdwheeler]

Fixed in #8148

[KalleOlaviNiemitalo]

I don't see how #8148 addresses this. The diff does not mention "libmi", and the occurrences of "mi" don't look relevant (most of them are in "Microsoft" or "terminal").