[SRU] revert security-regression in Focal's libcrypto++

[ Impact ]

Focal's libcrypto++ 5.6.4-9 regresses elliptic curve generation. Uploading
this version from Debian appears to have been a mistake.

This is a security regression, but was not published through the security
pocket.

As far as I am aware, Debian only packaged 5.6.4-9 in sid. Buster's latest
version is 5.6.4-8: the version immediately before the regression.

This version includes an _incomplete_ security patch for CVE-2019-14318
which breaks elliptic curve arithmetic.
 - https://github.com/weidai11/cryptopp/issues/869 states that this 5.6
   security patch is incomplete.
 - https://github.com/weidai11/cryptopp/issues/994#issuecomment-752399981
   states that the 2019 patch (which 5.6 and 8.3.0 received) has a
   regression.

See https://github.com/weidai11/cryptopp/issues/1269 and LP#2060564 for a
deeper exploration of this Ubuntu Focal issue.

The root cause of LP#1893934 appears to be caused by this regression.
  - As reported on the urbackup forums, rolling back to the previous
    version solves this crash.
 - https://forums.urbackup.org/t/urbackupsrv-crashes-on-ubuntu-20-04/

[ Test Plan ]

1. To test the regression:

Compile and use @ekera[@]github.com's PoC (attached as main.cpp):
```
$ g++ main.cpp -lcryptopp -o test
$ ./test
```

The PoC will report `X is *NOT* as expected.` on miscomputations.

See https://github.com/weidai11/cryptopp/issues/1269

Both Bionic 18.04.06 (libcrypto++ version 5.6.4-8) and Jammy 22.04.04
(libcrypto++ version 8.6.0-2ubuntu1) had the expected result. Focal fails
with 5.6.4-8. Rolling back the version allows the PoC test to past. Using
a version built with the attached debdiff also passes the PoC.

2. Package tests:

All package build tests pass regardless of the regression. Checking that
new failures do not occur is a sanity test.

To test builtin tests run: `cd /usr/share/crypto++ && cryptest v`

X. Note:

Unfortunately there are no autopkgtests.

`reverse-depends -r focal src:libcrypto++` includes five, possibly minor,
reverse dependencies.

libcrypto++ is mostly used as a dependency outside of the Ubuntu Archive.
i.e., we have low visibility on how this package is used.

I am hoping that the PoC and built in tests are enough to prove the sanity
of this security regression SRU.

[ Other Info ]

A big thank you to Martin Ekerå (@ekera[@]github.com) for identifying this
issue and writing a thorough bug report and PoC on GitHub \o/

This is my first SRU. I need a sponsor and help tagging on LP.

I have performed the Test Plan.

The fix solely involves on removing a d/patch file.

Removing the patch causes the following (expected) symbol changes in
./usr/lib/x86_64-linux-gnu/libcrypto++.so.6.0.0:
```
+CryptoPP::ProjectivePoint::~ProjectivePoint() W
+std::vector<CryptoPP::ProjectivePoint, std::allocator<CryptoPP::ProjectivePoint> >::~vector() W
+void std::vector<CryptoPP::ProjectivePoint, std::allocator<CryptoPP::ProjectivePoint> >::_M_realloc_insert<CryptoPP::ProjectivePoint const&>(__gnu_cxx::__normal_iterator<CryptoPP::ProjectivePoint*, std::vector<CryptoPP::ProjectivePoint, std::allocator<CryptoPP::ProjectivePoint> > >, CryptoPP::ProjectivePoint const&) W
```

[ Where problems could occur ]

Two systems both using software based on the regressed version of Crypto++
*could possibly* communicate through incorrectly generated keys together.
This seems unlikely and, if it is even possible, we should discourage or
even break the use of miscalculated elliptic curves.

A regression in reverting the regressed patch is possible.