[ANCHOR-809] Add sep31 methods to asset config and info response

[JiahuiWho]

Description

Add methods to sep31.receive in asset config per discussion.

Also add methods to Sep31InfoResponse. To keep consistency of the sep info response, new SEP-31 response will be look like this:

  {
    "receive": {
      "JPYC": {
        "enabled": true,
        "quotes_supported": true,
        "quotes_required": false,
        "min_amount": 0,
        "max_amount": 1000000,
        "fields": {
          "type": {
            "description": "methods supported by the anchor for asset deposits",
            "choices": ["SEPA","SWIFT"],
            "optional": false
          }
        }
      },
      "USDC": {
        "enabled": true,
        "quotes_supported": true,
        "quotes_required": false,
        "min_amount": 0,
        "max_amount": 10, 
        "fields": {
          "type": {
            "description": "methods supported by the anchor for asset deposits",
            "choices": ["SEPA","SWIFT"],
            "optional": false
          }
        }
      }
    }
  }

Testing

• ./gradlew test

Documentation

Will update protocol and anchor tests to reflect the change once we reached agreement on the new response format

[JiahuiWho]

In my opinion type is too general (i.e in SEP-12 type is used to refer customer type), we should use something more descriptive, maybe Payment Methods etc.

Also curious if we can get rid of the the nested fields: { types: { ... } } structure (This is also used in SEP-6 info response)? fields is mostly used to list needed KYC info, but now SEP-6 and SEP-31 both has delegate it to SEP-12

[philipliu]

In my opinion type is too general (i.e in SEP-12 type is used to refer customer type), we should use something more descriptive, maybe Payment Methods etc.

I think it's fine to call it type here because SEP-6 also calls the methods, type. Ideally, we rename both to something like method but I'm not sure it's making a protocol change so we can rename a field.

Also curious if we can get rid of the the nested fields: { types: { ... } } structure (This is also used in SEP-6 info response)? fields is mostly used to list needed KYC info, but now SEP-6 and SEP-31 both has delegate it to SEP-12

Makes sense to me. SEP-6 does this already and calls the config property, methods.

[JiahuiWho]

I think it's fine to call it type here because SEP-6 also calls the methods, type. Ideally, we rename both to something like method but I'm not sure it's making a protocol change so we can rename a field.

Right I also talked to Jamie about this and let's stick with type for now