Refine AddressParser interface

[msgilligan]

The AddressParser interface should probably change from:

public interface AddressParser {
    Address parseAddressAnyNetwork(String addressString) throws AddressFormatException;
    Address parseAddress(String addressString, Network network) throws AddressFormatException, AddressFormatException.WrongNetwork;

    @FunctionalInterface
    interface Strict {
        Address parseAddress(String addressString) throws AddressFormatException;
    }
}

to something more like:

@FunctionalInterface
public interface AddressParser {
    Address parseAddress(String addressString) throws AddressFormatException;

    interface NetworkAddressParser extends AddressParser {
        Address parseAddress(String addressString) throws AddressFormatException;
        Address parseAddressForNetwork(String addressString, Network network) throws AddressFormatException, AddressFormatException.WrongNetwork;
    }
}

This addresses the following issue with the current implementation:

1. There are many use-cases where the @FunctionalInterface is useful and in this context it could be "strict" or "non-strict" (i.e. may or may not check the Network.
2. "AnyNetwork" is a poor naming choice. It's "all networks known by the configuration of this parser"
3. A specialized exception should be thrown for the case of the network not matching the provided value (this means the @FunctionalInterface can be used in either way)

Make sure to scroll to the right to see the AddressFormatException.WrongNetwork being thrown. We may also want to refine the class hierarchy of AddressFormatException slightly to so that WrongNetwork is a separate case (not a subclass of) InvalidPrefix (aka unknown network) and perhaps even one new case should be added.

[schildbach]

I still don't understand the implications of functional interfaces and these specific changes. But if you think it's an improvement why not give it a try?

[msgilligan]

PR #3103 Uses a slightly different implementation than suggested above to address issues (1) and (2) above, but does not address issue (3).

[msgilligan]

PR #3101 was closed in favor of PR #3129, which has been merged.

[schildbach]

Is this issue still open for (3) above, or can it be closed because it has mostly been resolved?

[schildbach]

If not closed, I tend to defer this to 0.18 too.

[msgilligan]

Let's leave it open for at least another few days and I'll probably defer it to 0.18, but also open a new smaller issue for 0.17 and maybe create a PR to match. I also want to make a PR for validating already parsed addresses against networks as we recently discussed.

[schildbach]

My understanding is you created the "smaller PR" as #3384 and it was merged. So can we defer this to 0.18?

[schildbach]

I'm removing this as a blocker for 0.17, so that we can go ahead and branch off for beta/rc/release.