upgrade plux to 1.7

[thrau]

Motivation

This PR upgrade plux to 1.7 which provides python 3.12 support (see #10235). The PR also migrates plugin imports to the new way to do things (from plux import ...). Since 1.7 is backwards compatible, we can make these changes for ext separately.
Moreover, plux now has a way of regenerating entrypoints without invoking setup.py (which is deprecated), therefore unblocking us from moving away from a setup.py to python -m build.

We could also look into removing localstack.cli.plugins, and move some of the functionality to plux (if needed).

Changes

• localstack now uses plux>=1.7
• make entrypoints now uses the plux frontend python -m plux entrypoints instead of setup.py plugins egg_info
• localstack now favors from plux for imports instead of from plugin

[github-actions]

S3 Image Test Results (AMD64 / ARM64)

  2 files    2 suites   3m 11s ⏱️
386 tests 336 ✅  50 💤 0 ❌
772 runs  672 ✅ 100 💤 0 ❌

Results for commit 666b76e.

♻️ This comment has been updated with latest results.

[coveralls]

coverage: 83.856% (-0.004%) from 83.86%
when pulling e3cfa3a on upgrade-plux
into db3c42f on master.

[github-actions]

LocalStack Community integration with Pro

    2 files  ±0      2 suites  ±0   1h 21m 38s ⏱️ - 1m 1s
2 642 tests ±0  2 395 ✅ ±0  247 💤 ±0  0 ❌ ±0 
2 644 runs  ±0  2 395 ✅ ±0  249 💤 ±0  0 ❌ ±0 

Results for commit 666b76e. ± Comparison against base commit db3c42f.

♻️ This comment has been updated with latest results.

[alexrashed]

The changes are looking good! The release implements a nice deprecation path, and can seamlessly be upgraded. 🔝
I only found a small nitpick, and I think it would be a good opportunity to discuss upper version limits in the setup.cfg.

[alexrashed]

I think this is a good opportunity to discuss upper version limits.
We explicitly removed pins like this in #10195.
We did this because there's no need for the pins for as long as the currently released version is compatible.
New releases will either be picked up proactively by us (in PRs like this, explicitly upgrading a single dependency), or they are picked up by the weekly upgrades where the breaking changes are identified and (a) fixed in the PR by adding a small fix, or (b) pinned and explicitly upgraded in a follow up PR (where the min version is updated and the upper version limit removed).
In this case, the library is maintained by us, meaning that we already explicitly know that 2.0 will contain breaking changes. However, if the person who creates the release does not proactively update it here, we most likely won't find out (because the automated updates won't dare to touch it 😛)...
This is why I am leaning towards not having these pins, but again, this is a great opportunity to discuss them. 😄

[alexrashed]

Sorry for the initial "comment" instead of the approval, that was a mistake.
I am happy with merging this as it is, but I would be happy to discuss the comment concerning the upper version limit. 😄

[alexrashed]

FYI: Due to the nice deprecation path / backwards compatibility of the changes in plux==1.7.0, the requirements lock files have already been updated with #10270. This PR will basically just contain the code changes and the change in the setup.cfg.