[SEP-31] Add methods to info response and update fields desc

[JiahuiWho]

1. This is part of the ticket https://stellarorg.atlassian.net/browse/ANCHOR-809, where methods were introduced to assets config to represents the deposit methods supported by anchor. To align the config and info response across SEPs, adding methods to SEP-31 info response

2. Also adjust the desc of fields to reflect the change.

3. Minor fix of broken pending-transaction-info-update reference

[JakeUrban]

SEP-6 uses the fields object provided in GET /info responses to inform clients what the supported values are for the type request parameter in GET /deposit-exchange and GET /withdraw-exchange.

There is no type parameter in SEP-31's POST /transactions endpoint, so the fields object currently doesn't serve a purpose. I think in order for this to be valuable, we need to add a type parameter to this endpoint.

[JiahuiWho]

Can we use the fields object just for display purposes? Even without a type parameter in SEP-31, it's meaningful to inform clients about the deposit types supported by the anchor. Otherwise the methods is not being used anywhere in the anchor platform either.

I remember that fee_fixed and fee_percent used to be included in the info response, and they are not being used at all (stellar/java-stellar-anchor-sdk#1483). I wonder if those two are for informational use as well?

[JakeUrban]

Clients can already use SEP-38 to see what an anchor's supported buy and sell methods are, so providing that information in the SEPs /info endpoints is already a bit redundant. Thats also the reason why we don't support fee_fixed and fee_percent in the anchor platform -- SEP-38 provides better support for communicating fee details.

[philipliu]

Can we use the fields object just for display purposes? Even without a type parameter in SEP-31, it's meaningful to inform clients about the deposit types supported by the anchor. Otherwise the methods is not being used anywhere in the anchor platform either.

I think we need the client to provide the type, otherwise the anchor would not know what KYC fields to request.

[lijamie98]

Since we are adding type to fields, I think we should remove deprecated.

[JakeUrban]

Neither of these descriptions quite make sense. The original version of the fields object schema looked like this:

{
  "fields": {
    "transaction": {}
  }
}

We deprecated fields because its only purpose was for transaction to specify request parameters required to be sent in POST /transactions requests.

Now that we're adding type, I think we have a couple options:

• Deprecate fields.transaction specifically, and un-deprecated fields. This way we can add the type key to the fields object:

{
  "fields": {
    "type": {
      "description": "",
      "choices": [],
      "optional"
    }
  }
}

• Un-deprecate both fields and field.transaction, and add type as a subfield of field.transactions:

{
  "fields": {
    "transaction": {
      "type": {
        "description": "",
        "choices": [],
        "optional"
      }
    }
  }
}