remove DSS key references; upgrade paramiko dependency to version 4.0

[rawwar]

Raising this PR as Apache Airflow uses this package. We wanted to bump paramiko>=4.0.0(PR). But, found that sshtunnel uses DSS Key. I did see earlier PR's. But, they were failing tests. This is my attempt to try to fix them.

• removed DSSKey usage
• updated min. version of paramiko to 4.0
• updated min. python version to 3.9
• dropped support for python 2.x
• fixed failures of docs tests in circleci
• updated changelog, docs
• updated appveyor config - This is still failing. Not sure how to fix

Note: I've used copilot

[coveralls]

coverage: 91.704% (+0.04%) from 91.667%
when pulling b93a5e9 on rawwar:kalyan/bump_paramiko
into dc07328 on pahaz:master.

[rawwar]

Looks like, its not possible to enable rolling build from appveyor.yml config. it needs to be done via UI - https://www.appveyor.com/docs/build-configuration/#rolling-builds

Appveyor builds are running for every commit. I think, we don't need the older builds running when the PR is updated .
CC: @pahaz

[rawwar]

@pahaz , I did make a lot of changes in the PR assuming too many things. Appreciate your feedback and how we want to resolve this.

[rawwar]

Also, for Appveyor config, do you know what will be the python path? I did some debugging and still was unable to figure it out. I did try adding more debug logs.

[wenderson-cmp]

any updates ? @pahaz

[lozik4]

Maybe release 0.4.1 where bamp paramico <=3.5.1
After that, release 0.5.0 without support DSSkey
@pahaz ?

[akozlu]

Hi @pahaz, following up on this. The suggestion from @lozik4 about a phased release (0.4.1 with paramiko <=3.5.1, then 0.5.0 without DSS key support) seems like a reasonable path forward. Would that approach work?

[pahaz]

Thanks for your tremendous work — really appreciate it! 🙌

I’d like to keep basic compatibility with older Paramiko and Python 2 for now. The library is used in closed environments where upgrades are slow, so a softer transition would help. I agree with #309 it will be the best for now.

My proposal:

• Ship an intermediate release that keeps support for older Paramiko.
• In the next release, proceed with the backward-incompatible changes.

Happy to help with testing this path. I’ll revisit this PR a bit later.

[eladkal]

My proposal:
Ship an intermediate release that keeps support for older Paramiko.
In the next release, proceed with the backward-incompatible changes.

Is it reasonable to consider both in parallel?
You can set a branch for older version and keep master for new breaking change release
thus keep releasing 0.x.y from the old branch and releasing 1.a.b from master branch.
You can keep releasing both to PyPi.