Support stellar-core protocol 13 (CAP 18) - "Fine-Grained Control of Authorization"

[abuiles]

The upcoming stellar-core protocol 13 release will add support for CAP 18 ("Fine-Grained Control of Authorization").

Horizon

• Add is_authorized_to_maintain_liabilities to balance attributes
• Add authorized_to_main_liabilities to operation details when Op is OperationAllowTrust https://github.com/stellar/go/blob/protocol-13/services/horizon/internal/expingest/processors/operations_processor.go#L260
• Extend AllowTrust in protocols to include Flags https://github.com/abuiles/go/blob/e12b580711a108b61a53bc58891ca2916f054c5a/protocols/horizon/operations/main.go#L191-L197 -
• Add a new effect called history.EffectTrustlineAuthorizedToMaintainLiabilities https://github.com/abuiles/go/blob/e12b580711a108b61a53bc58891ca2916f054c5a/services/horizon/internal/expingest/processors/effects_processor.go#L539-L559
• Add history.EffectTrustlineAuthorizedToMaintainLiabilities to effects resource adapter https://github.com/abuiles/go/blob/e12b580711a108b61a53bc58891ca2916f054c5a/services/horizon/internal/resourceadapter/effects.go#L100-L103
• No changes are required in the trustline ingestion processor flags are already handled as an int.

Backward compatibility
Since the binary representation of bool authorize is the same as uint32 authorize for true or false, we can roll this changes in Horizon and SDKS before protocol 13 is deployed to stellar core.
They'll only have problems if they try to set authorize to AUTHORIZED_TO_MAINTAIN_LIABILITIES_FLAG since it won't be recognize by protocol 12.

Again, if the CAP doesn't go through, we can roll the changes in a safe manner.

[abuiles]

@ire-and-curses @tamirms @bartekn I think this is all we need for cap 18 support. I put a question in the requirements, we could combine both flags or we could expose both flags in the balances payload. I'd prefer to expose the new flag so it's clear for final users what's the actual state of the trust line.

Alternatively, we could also add the attribute flags as an int - what I like about this approach is that we won't have to add new attribute if there are new flag types and then let the SDKs implement helper methods.

cc @jonjove

[tomerweller]

I'm not a fan of having the authorization state spread across two booleans. Nor am I a fan of of having a bit masked integer as part of horizon's json api.

I propose:

• Softly deprecating the is_authorized boolean as it no longer conveys the full state of authorization. This field should only be true if the trustline has the AUTHORIZED_FLAG set.
• Introduce a new status string field with one of three values: "authorized" | "authorized_to_maintain_liabilities" | "unauthorized" . It's ugly and verbose, but hey that's json :)

[jonjove]

@tomerweller If you change to a "status" string field, how would you plan to deal with a future where there are flags that aren't mutually exclusive?

[abuiles]

@tomerweller I agree we should probably start soft deprecating is_authorized - however, as @jonjove pointed out, there might be a scenario where the flags aren't mutually exclusive.

I discussed this briefly with @tamirms and we'll do the following:

1. Soft deprecate is_authorized and make it be true only if AUTHORIZED_FLAG is true as @tomerweller suggested.
2. Add the flags attribute and let the SDKs implement helpers around it.

[tomerweller]

@jonjove you're right - I was under the assumption that states will be mutually exclusive.

In that case maybe adding multiple boolean fields is indeed the "jsony" way to go.

@abuiles and @tamirms, I'd say that adding fields that require an SDK to understand is a step in the wrong direction. Horizon's query results currently don't require that.

This is not theoretical. When I write tools that query horizon I don't bother bringing in an sdk dependency. It would be great to keep it like that.

[abuiles]

@tomerweller good point! Also if you read the issue, we'll have to do something similar to list effects. So we are back to the original plan.

[abuiles]

Fixed in #2423