If this doesn't depend on #4238, I think it should be rebased without that
history -- I don't feel totally comfortable executing the cherry-pick
operation described here. However, it looks like the dependent PR will be merged
shortly so I'll just wait until that one is merged to review this one.

Hello, this PR is ready for review

while reviewing this PR, I haven been experimenting with accessing a
v3.14.1 cluster with this version of fly, to try to get more insight into this
snippet:

func unmarshalToken(tokenValue string) (map[string]interface{}, error) {
	tokenContents := strings.Split(tokenValue, ".")
	if len(tokenContents) < 2 {
		// this is really bad and makes it hard to write proper integration tests
		return nil, nil
	}

I hope to finish this experiment tomorrow.

We got rid of the testflight tests we were adding because it does not provide any new coverage. Everything it tested is already covered by the API unit tests or the fly integration tests.

In order to break the testflight tests we added we would have to do one of the following:

1. break fly, but any breaks would be caught by fly/integration
2. break the API, but the unit tests would catch any breaks there

Therefore we're already covered by existing tests and don't need the new testflight tests.

This is ready for review again @pivotal-jamie-klassen