Wrong installation path for the sssd Python module

[ Impact ]

sssd users who try to invoke the "sssctl analyze" command on Ubuntu Jammy will experience the following error:

/usr/bin/env: ‘python’: No such file or directory

This happens because "sssctl analyze" will call /usr/libexec/sssd/sss_analyze, which uses "#!/usr/bin/env python" as its shebang. This is incorrect, as it should be using "python3" instead.

When this bug is fixed, another one pops up:

Traceback (most recent call last):
  File "/usr/libexec/sssd/sss_analyze", line 3, in <module>
    from sssd import sss_analyze
ModuleNotFoundError: No module named 'sssd'

This bug is happening because sssd-tools currently installs its Python files inside /usr/lib/python3.10/site-packages/sssd/, but the right path to install these files is /usr/lib/python3/dist-packages/sssd.

[ Test Plan ]

$ lxc launch ubuntu-daily:jammy sssd-bug1979453
$ lxc shell sssd-bug1979453
# apt update
# apt install -y sssd sssd-tools
# cat > /etc/sssd/sssd.conf << _EOF_
[sssd]
config_file_version = 2
services = pam
domains = example.com

[pam]

[domain/example.com]
id_provider = proxy
proxy_lib_name = files
auth_provider = krb5
krb5_server = localhost
krb5_realm = EXAMPLE.COM
_EOF_
# chmod 0600 /etc/sssd/sssd.conf
# sssctl analyze

With the current version of sssd available in Jammy, you should see the error messages listed above (in the "Impact") section. With a fixed sssd, you will see:

# sssctl analyze
usage: sss_analyze [-h] [--source {files,journald}] [--logdir LOGDIR] COMMANDS ...

Analyzer tool to assist with SSSD log parsing

options:
  -h, --help show this help message and exit
  --source {files,journald}
  --logdir LOGDIR SSSD Log directory to parse log files from

  COMMANDS
    Modules
      request Request tracking

[ Where problems could occur ]

This fix changes the path where sssd's Python files are installed. I believe this is the most problematic part of this SRU: although we doing "the right thing" here, there is always the possibility that someone might have a local script that somehow relies on the Python files to be where they currently are. This would obviously be an unsupported scenario, but nonetheless it could break this person's script. I find it highly unlikely that this will happen, though, because this bug did not exist until very recently ("sssctl analyze" has been introduced only on Jammy).

[ Original Description ]

Context
---------

```
# lsb_release -rd
Description: Ubuntu 22.04 LTS
Release: 22.04
```

 Symptoms
----------

The `/usr/libexec/sssd/sss_analyze` tool, invoked through `sssctl analyze`, is broken under Ubuntu 22.04:

```
# sssctl analyze --help
Traceback (most recent call last):
  File "/usr/libexec/sssd/sss_analyze", line 3, in <module>
    from sssd import sss_analyze
ModuleNotFoundError: No module named 'sssd'
Command '/usr/libexec/sssd/sss_analyze' failed with [1]
```

 Cause
-------

The tool is brought by the `sssd-tools` package, which also comes with the expected Python module named `sssd`:

```
# dpkg -S /usr/libexec/sssd/sss_analyze
sssd-tools: /usr/libexec/sssd/sss_analyze
# apt-cache show sssd-tools
Package: sssd-tools
Architecture: amd64
Version: 2.6.3-1ubuntu3
Priority: extra
Section: utils
Source: sssd
Origin: Ubuntu
...
Depends: python3, python3-sss, python3-systemd, sssd-common (= 2.6.3-1ubuntu3), libc6 (>= 2.34), libdhash1 (>= 0.4.0), libldb2 (>= 0.9.21), libpam0g (>= 0.99.7.1), libpopt0 (>= 1.14), libref-array1 (>= 0.4.0), libsss-certmap0 (>= 2.6.3), libtalloc2 (>= 2.0.4~git20101213)
...
Filename: pool/main/s/sssd/sssd-tools_2.6.3-1ubuntu3_amd64.deb
Size: 92454
MD5sum: ed023079efa434dbfefb0a11488be6be
SHA1: 28f44521c11ae93f774b907ef13aaec271f5db77
SHA256: b4954b7ec32bbc21fa77ecc5a68f3ddd682bf4408ad029bfc403367dc7dc657b
SHA512: 693eaa32af1dd9ffbbfc6a553ea9db72e76d9e5d1567da83d9356db21ad462927e4a3c20773f17a914115e89d1e62c66b28d529c52642d7f9f58d8d812113e83
...
# dpkg -L sssd-tools
...
/usr/lib/python3.10/site-packages/sssd
/usr/lib/python3.10/site-packages/sssd/__init__.py
/usr/lib/python3.10/site-packages/sssd/modules
/usr/lib/python3.10/site-packages/sssd/modules/__init__.py
/usr/lib/python3.10/site-packages/sssd/modules/request.py
/usr/lib/python3.10/site-packages/sssd/parser.py
/usr/lib/python3.10/site-packages/sssd/source_files.py
/usr/lib/python3.10/site-packages/sssd/source_journald.py
/usr/lib/python3.10/site-packages/sssd/source_reader.py
/usr/lib/python3.10/site-packages/sssd/sss_analyze.py
...
```

Unfortunately, it gets installed into the `site-packages` subdirectory of `/usr/lib/python3.10`, whereas Python is configured to only search the `dist-packages` subdir:

```
# python
Python 3.10.4 (main, Apr 2 2022, 09:04:19) [GCC 11.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.path
['', '/usr/lib/python310.zip', '/usr/lib/python3.10', '/usr/lib/python3.10/lib-dynload', '/usr/local/lib/python3.10/dist-packages', '/usr/lib/python3/dist-packages']
```

 Solution proposal
-------------------

Ship a new release of the package with the module installed into `dist-packages` instead of `site-packages` under `/usr/lib/python3.10`.