[spaceship] handle new app status

[lucgrabowski]

Checklist

• I've run bundle exec rspec from the root directory to see all new and existing tests pass
• I've followed the fastlane code style and run bundle exec rubocop -a to ensure the code style is valid
• I see several green ci/circleci builds in the "All checks have passed" section of my PR (connect CircleCI to GitHub if not)
• I've read the Contribution Guidelines
• I've updated the documentation if necessary.
• I've added or updated relevant unit tests.

Motivation and Context

There are changes in app statuses on Appstore Connect and in OpenAPI spec (https://developer.apple.com/documentation/appstoreconnectapi) as mentioned in https://developer.apple.com/news/releases/?id=02082024e and #21877.
There is a new enum AppVersionState for AppStoreVersion and there is also a new enum State for AppInfo.
AppStoreVersion was also enhanced with reviewType property.

Description

After new Appstore Connect API release AppStoreVersion has two properties related to state: AppVersionState and AppStoreState. Similarly AppInfo has State and AppStoreState.
As written in release notes https://developer.apple.com/documentation/appstoreconnectapi/app_store_connect_api_release_notes/app_store_connect_api_3_3_release_notes

appStoreState attribute is now deprecated and replaced with appVersionState in the object [AppStoreVersion.Attributes]
...
appStoreState attribute is now deprecated and replaced with state in the object [AppInfo.Attributes]

There is a change in meaning of statuses https://developer.apple.com/news/releases/?id=02082024e:

Ready for Sale has been renamed to Ready for Distribution, and now indicates that your app can be published. To view if your app is available on the App Store, visit Pricing and Availability.
Developer Removed from Sale, Removed from Sale, and Pending Agreement are no longer app statuses.

Some observations:

1. When app is removed from sale by developer, instead of DEVELOPER_REMOVED_FROM_SALE, we will get an AppStoreVersion with attributes:

"appStoreState" : "READY_FOR_SALE",
"appVersionState" : "READY_FOR_DISTRIBUTION",

and the only way to see if the app is live or removed is to check available territories using Pricing and Availability list or use URL: https://appstoreconnect.apple.com/iris/v2/appAvailabilities/<XXXXXXX>?include=territoryAvailabilities&limit[territoryAvailabilities]=200 request (currently not implemented in fastlane)

2. When developer program membership is expired, instead of PENDING_CONTRACT status for released version, we will get an AppStoreVersion with attributes:

"appStoreState" : "READY_FOR_SALE",
"appVersionState" : "READY_FOR_DISTRIBUTION",

and when we check in Pricing and Availability, territories are available but with status CANNOT_SELL as in example:

"type" : "territoryAvailabilities",
    "id" : "...",
    "attributes" : {
      "available" : true,
      ...
      "contentStatuses" : [ "CANNOT_SELL" ]
    },

Testing Steps

N/A

[lacostej]

LGTM.

Do we need to update any tools to use these statuses?

Some of the observations you made makes me wonder if we should provide high level functions to determinate when an app is remove from sale or the developer membership is expired.

[lucgrabowski]

@lacostej Thanks for review.
There are several different things that I would like to mention, so I'll list them with numbers to be able to discuss it further, some of those things should be discussed outside of this pull request.

1. I think that new statuses could be applied in filtering methods in App model and in Deliver::SubmitForReview.
   It looks like the change could be applied 1 to 1, of course along with renaming property used filter in requests.
   That would require testing deliver, uploading and downloading metadata, screenshots, generating html summary, downloading dsyms, actions (SetChangelogAction, AppStoreBuildNumberAction, DownloadDsymsAction), Precheck::RuleProcessor

2. Those high level methods that you propose could be useful. If we want to check if app is removed from sale we would have to implement a new request for checking app availability territories
   https://developer.apple.com/documentation/appstoreconnectapi/read_app_availablity_territories.
   Implementing new endpoint (v2) will require changes to client, as it has v1 hardcoded in hostname.
   

   fastlane/spaceship/lib/spaceship/connect_api/tunes/client.rb

   Line 22 in 385a15f

   'https://appstoreconnect.apple.com/iris/v1/'

   
   I tried getting app availability data using deprecated v1 api, but without luck.

3. I think that we should skip checking app availability to understand if it's PENDING_CONTRACT.
   There is a lot of content statuses possible https://developer.apple.com/documentation/appstoreconnectapi/territoryavailability/attributes. I noticed that there is the same content status (CANNOT_SELL) for both cases - when account membership is expired or app is removed from sale, .
   A better way of checking membership expiration would be checking portal teams status (active or expired).
   

   fastlane/spaceship/lib/spaceship/portal/portal_client.rb

   Lines 42 to 51 in 385a15f

   	def teams
   	return @teams if @teams
   	req = request(:post, "account/listTeams.action")
   	@teams = parse_response(req, 'teams').sort_by do |team|
   	[
   	team['name'],
   	team['teamId']
   	]
   	end
   	end

4. And one more thing which I think is important, even though not related to this PR.
   Fastlane currently updates territory availabilities when uploading metadata (Deliver::UploadPriceTier) using a deprecated method, by modifying App
   https://developer.apple.com/documentation/appstoreconnectapi/modify_an_app
   https://developer.apple.com/documentation/appstoreconnectapi/appupdaterequest/data/relationships.
   Price tier is also updated in this request and also it is a deprecated method.