Support AE dev appserver

We need to understand what is the desired expectation when using gcloud-java on AE dev appserver.

The options are:

use local services
use production services

An issue with option (1) is that currently local dev app services such as Datastore are not accesible via the cloud interface (apiary or gRpc).

An issue with option (2) is that the current implementation detects that we are running on AE and automatically chooses the projectid and authentication mode.
This is nice and convenient in production but is an issue with dev appserver as the AppEngineAuthCredentials is based on AppIdentity which
will not work against production when used by dev appserver.

@ludoch

/cc @ludoch @pcostell

Note that it is possible to use gcloud-java with dev appserver by explicitly specifying projectId (if different from the local appid) and using ApplicationDefaultAuthCredentials but I think the goal should be to make the same code work in both modes (prod or dev).

Also, choosing this option seems to omit a warning.

When you say AE dev app server, do you refer to the Python Devappserver that can also support Java Web apps for Cloud SDK integration or the current Java GAE SDK classic?

I think we have the same issue for both types of dev appserver and I think we should provide the same solution for both cases.

Though if we can only deal with one than I would say the non-classic is more important.

@lesv

/cc @lesv @tmatsuo @saturnism

Why won't DefaultAuthCredentials work if gcloud init has been run? That has both user credentials and a project ID.

+1 to DefaultAuthCredentials. however iirc, appengine credential is a service account where you can add additional scopes, but gcloud auth login could've been a 3LO oauth2 where the scopes were predetermined during the authorization request. there is no way to add another scope except to re-auth...

What do you think about the option of routing the calls to local services (fakes/emulators) when we detect that we run in a local dev appserver environment?

i feel that's a good default behavior, what if they do want to run it against a remote server?

I think they should be able to do that by explicitly specifying the production host of the service,
its project id and using ApplicationDefaultAuthCredentials (which works today).