Associate each application with a user specified public or private auth-protected registry

[shaunsmith]

It's not reasonable to limit an Fn server to a single public or private registry (see #955). Users will want to identify the registry where the functions for a given application are available. This means registry configuration is not at the server level but at the app level, although it seems reasonable for an Fn server to have a default registry configured.

This requires that the Fn server safely store the user provided creds required to access a private registry.

[shaunsmith]

@rdallman any chance we're going to get to this soon, like V1.0?

[rdallman]

we can prioritize this. will leave the 'what's in v1.0' convo alone :)

it needs some API design work and is likely worth considering how best to maneuver users that put multiple credentials for the same registry on one app (meaning, we have to loop over credentials until one works and this doesn't create a great user experience necessarily -- the upside is it's more convenient to 'log in' to an app once and use it for multiple images). this attempts to align with a 'docker login' like flow but fn and docker aren't perfect analogues so it is worth thinking about anyway, the app solution is good but seems like we may be able to do better, but maybe not!

will try to explain the problem/solutions/tradeoffs a little more here and get some opinions