1) Having the TLS stack trust a "custom CA" provided by any number of debug tools (like mitmproxy or OWASP Zap) is relatively simple operation and can be done by anyone on any OS as long as you have admin/root.
2) There are a number of additional debug ways to decode the encryption from an application endpoint (e.g. https://wiki.wireshark.org/TLS and look at SSLKEYLOGFILE environment variable supported by most major TLS stacks and all major browser). Since MitmProxy2Swagger also supports HAR format ingest (e.g. https://github.com/alufers/mitmproxy2swagger#HAR ), this can easily be exported from any browser built-in debug tools (which also removes the encryption).
Modern TLS is great, but there are limitations on what it actually provides especially around the CA trust model. These mitm tools are not designed to take random traffic from the internet you intercepted, they require privileged endpoint access to enable specific debug features or configurations.
This is only a problem if a client application has a server certificate pinned in source code. Otherwise, you can create a cert with a privacy CA and add it to a desktop OS trusted cert store.
Adding a CA cert to the OS trust store only works if the application uses it. I've encountered apps that don't use the OS trust store or networking stack; even then it's possible to reverse engineer the traffic though[0].