cleanup: HUMAN_RE regexes in uri.py are never used

[davidsarah]

From src/allmydata/uri.py​:

# "human-encoded" URIs are allowed to come with a leading
# 'http://127.0.0.1:(8123|3456)/uri/' that will be ignored.
# Note that nothing in the Tahoe code currently uses the human encoding.

We should remove the dead code related to "human encoding" and instead make the normal parsing of URIs more tolerant: see #942, #884, and #885.

[davidsarah]

src/allmydata/uri.py: Remove unused 'human encoding' methods, and associated tests. fixes #1807

[zooko]

Why not use the "human encoding" parser of URLs instead of removing it and making the normal parsing of URLs more like it?

[davidsarah]

Replying to zooko:

Why not use the "human encoding" parser of URLs instead of removing it and making the normal parsing of URLs more like it?

Because:

• there's no ticket proposing to allow an http://... prefix for Tahoe URIs, and I don't think we want that.
• the human encoding parsers don't implement #884 or #885. They partially implement #942, but inconsistently, for example most of the ":" characters can be replaced by "%3A" (matched case-sensitively, which is wrong), but the one before an MDMF extension field cannot. This is because the human encoding implementation approaches this in a suboptimal way: we should be %-unencoding the whole Tahoe URI rather than treating ":" as a special case.
• making this change has very little regression risk because it is only dead code that is being removed.
• most of the work of implementing #942, #884, and #885 is in adding and repairing tests, the non-test code changes are straightforward. So not much effort is actually saved by reusing the human encoding code.

[zooko]

Okay, I agree! I scanned this patch and it looks good because it is all code-removal.