[RM] Remove src:ntopng from Impish - and maybe src:ndpi as well

Hi,

src:ntopng - program to monitor traffic
src:ndpi - library only used in/for ntopng

There were issues around s390x failing an binary removals, but that isn't all of it.
Just from history one would expect this to build only for some architectures,
but on those to be fine and migrating.
What I found was a bit more complex.
Bionic (3.2+dfsg1-1): amd64, arm64, i386
Focal (3.8+dfsg1-2.1build3): amd64, arm64, armhf, i386, ppc64el, s390x
G/H/I (3.8.1+dfsg1-1build2): amd64, armhf
H/I (3.8.1+dfsg1-1build3) bdep ok on all but s390x, all FTBFS with ndpi 3.4

Let me try to summarize as a timeline:

# December 2019

Uploads of ndpi 3.0 and ntopng 3.8.1 by the maintainer - things seemed to work back then and
migrated to release.

# Summer 2020

It was found that s390x has problems and that caused quite some work ending in s390x to be officially not supported.

1. Michael Hudson-Doyle <email address hidden>
   Tue, Jun 9, 2020, 4:35 AM
   There is a mess around ndpi / ntopng. Debian started a transition to ndpi 3
   some time ago but it ftbfs on some arches and the maintainer seems to have
   given up. Some guy called "Dimitri" tried to engage with upstream on the big
   endian problems: https://github.com/ntop/nDPI/issues/843

2. Steve Langasek <email address hidden>
   Tue, Aug 25, 2020, 8:08 AM
   ntopng and ndpi: the ndpi removal was based on per-arch build failures.
   But this means any new upload of ndpi to Debian that does /not/ fix these
   per-arch build failures will still be migratable to the release pocket,
   with a reduced set of supported archs. So there's not actually any
   reason to do a sourceful removal of ndpi, as opposed to a removal of the
   binaries on the regressed archs. So I've restored both ndpi and ntopng,
   which should both be releasable on a reduced set of archs.

# Summer 2020 in Debian

The same reasons blocked ntopng in Debian and it was eventually removed for not getting enough help to migrate
=> https://tracker.debian.org/news/1154992/ntopng-removed-from-testing/

# Winter 2020/2021

nDPI had CVEs and a few friendly helpers bumped that to 3.4 in Debian which also got synced.
See this update on the current FTFBS bug by Daniel Bungert here:
=> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977805#10

---

# What now?

If you only look at build logs one thinks "hey last time that built" but those (Focal / Debian-unstable) all were against the older ndpi 3.0.

So currently this isn't about s390x anymore (which was officially stated as not supported
and ignored since then).
It is about ndpi 3.4 making it an FTBFS.

So either we get it back to build and migrate or we also need to consider
to remove it like it is in Debian.
I've had a look and found that there is a ntopng version released after
ndpi 3.4 that makes it work (passes the FTFBS).

I have confirmed that ntopng 3.8.1 from git fails the same way as our FTBFS.
And 4.2 from git works.

So we could update this to 4.2 to make it pass one might think - I tried.
I thought "While I have no expertise in this package bumping it as-is might
provide more function than removing it"
But while checking how much effort it might be I also found that this is a DFSG
without an easily followable documentation what needs to be re-packaged.
Furthermore there are some changes to the fonts-awesome usage which also have an
open bug.
  => https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989115
And then while try-building it ran into other issues that seemed resolvable,
but need someone with a use-case for the software to try and verify it is fine.
Overall that is the final nail in the coffin on removal>update.

So I decidede to filed this launchpad bug to explain all this and ask for a removal to resolve the situation for now.

Bonus:

One has to remember that ndpi only exits for ntopng it seems to have no
other dependency.
$ reverse-depends --release impish src:ntopng
$ reverse-depends --release impish src:ndpi
Reverse-Depends
* ntopng (for libndpi3.0)

So if removing ntopng why keep ndpi?
This is up to the archive-admins who resolve this if they want the lib to be removed as well or keep it around without a consumer.