Changes

vty: always emit reject-cause lines in saved config

When reject-cause (not-found|no-proxy) setting was added, it was
implemented such that the new setting is not written into saved
config files if it equals the default of 'imsi-unknown'.  Change
this behavior to always write out the current setting for each of
not-found and no-proxy, whether or not they match compiled-in
defaults.

Change-Id: I18708fc1c08a85e98582c97ec59dd3822a0767fb

change default reject cause to plmn-not-allowed

Unless the Osmocom-based network operator has very carefully
considered what they are doing, returning MM/GMM reject cause #2
(IMSI unknown in HLR) to LU requests from bystander phones is a
very bad idea.  Here is what typically happens when someone sets
up an Osmocom-based GSM network for development, testing or
research, without roaming interconnection with any commercial
operators:

* Even when the private network operates its BTS at very low power
  levels, bystander phones in close proximity (e.g., in directly
  adjacent neighbor apartments or office suites) will receive a much
  stronger signal from the private/test network BTS than from any
  commercial operator, i.e., the private/test network will be
  the strongest signal.

* Many phones will attempt to "jump ship" to this strongest signal
  even if it broadcasts a completely unknown PLMN ID that is not in
  the preferred operator list, and even when they were previously
  not roaming at all, registered to their most preferred home operator
  with perfectly good reception quality.

* If these wayward phones receive reject cause #2 in response to their
  LU attempt, the spec effectively requires them to go into a "black
  hole" where they no longer attempt to register to any operator,
  including their own legitimate one.

Returning reject cause #11 instead (PLMN not allowed) solves this
problem: wayward phones that erroneously attempted to register to the
private/test network go back to their own legitimate commercial
operator, and everyone is happy.

This bug should be considered critical: when the reject cause is set
to #2 by default, any private Osmocom-based network, no matter how
low-power, will effectively cause service disruption to all nearby
commercially-served phones even when there is no clash in terms of
used radio frequencies.

Change-Id: Icff1d19670c398b119ec68b1d5f0fad87b605702

change default no-proxy reject cause to net-fail

If LU has to be rejected because DGSM mechanism cannot reach the
needed HLR, then returning reject cause #17 (Network Failure)
is the most accurate and truthful description of what is actually
happening.

Reject cause #2 (IMSI unknown in HLR) is unlikely to be a good
choice: in areas where regular commercial cell services are present
alongside with experimental/adventurous Osmocom-based GSM networks,
this reject cause is acutely dangerous as described in the previous
commit, and even in areas where no regular commercial cell services
are present (the presumed intended use case for DGSM), the behavior
of commanding LU-failing phones "please don't ever again try to
connect to ANY network until the user power-cycles you" is unlikely
to be correct/desirable.  If that behavior _is_ desired, it should
be configured explicitly, not by default.

Change-Id: I557ae1d3291066a87228b5db4f2e207ea721329c