ipn: get rid of Prefs.AllowSingleHosts?

[bradfitz]

Nobody sets Prefs.AllowSingleHosts to false. We use its default true value and only notice that the pref exists when there's a mistake and we accidentally use a ipn.Prefs zero value rather than use ipn.NewPrefs.

Maybe we should just ditch the field.

If they really really want to disallow single hosts, we can add a new pref (or envknob?) later that's named in the negative.

Thoughts?

/cc @maisem @oxtoacart @andrew-d @danderson @sailorfrag

[oxtoacart]

Interesting thought. In theory, the same thing could apply to several things that we initialize in NewPrefs().

• CorpDNS -> DisableCorpDNS
• AutoUpdate.Check -> AutoUpdate.DisableCheck
• AutoUpdate.Apply -> AutoUpdate.DisableApply

RouteAll:         true,
		AllowSingleHosts: true,
		CorpDNS:          true,
		WantRunning:      false,
		NetfilterMode:    preftype.NetfilterOn,
		AutoUpdate: AutoUpdatePrefs{
			Check: true,
			Apply: opt.Bool("unset"),
		},

I also noticed that AcceptRoutes is a little strange - the CLI up command defaults it to a platform-dependent value. I'm not sure what (if anything) our other clients do with it.

[bradfitz]

I'm explicitly not proposing doing this for CorpDNS and Auto-update. Those can very reasonably be off. They're much more subjective. I wouldn't want to invert those checks every time opinions change.

I'm not proposing this as a fix for the Start woes.

I just remembered AllowSingleHosts and how useless it was.

[danderson]

The field exists purely because the first customer, in the earliest days, wanted pure subnet routing with no client<>client connectivity, and ACLs didn't exist yet. This was the big hammer to ensure clients could only use subnet routes.

It's been vestigial the entire time I've been here. It can be removed.