Handle zero weights in cluster and non-cluster mappings, add new tests

[aricart]

• previously zero weights were interpreted as being 100
• added tests verifying the partial weights with 0 entries
• deprecated GetWeight method in favor of directly using the Weight field (this is the function that made 0 -> 100)
• this change enables JWT mapping configurations to eliminate traffic on a subject (0 is now possible)

Fix nats-io/nsc#775

[coveralls]

Pull Request Test Coverage Report for Build 19439588169

Details

• 16 of 19 (84.21%) changed or added relevant lines in 1 file are covered.
• 2 unchanged lines in 1 file lost coverage.
• Overall coverage decreased (-0.06%) to 81.015%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
v2/account_claims.go	16	19	84.21%

Files with Coverage Reduction	New Missed Lines	%
v2/account_claims.go	2	83.64%

Totals
Change from base Build 16832725450:	-0.06%
Covered Lines:	2778
Relevant Lines:	3429

---

💛 - Coveralls

[aricart]

This is actually not going to work - the previous implementation relied on the fact that if the weight was not specified - defaulted to 0, the value was interpreted as 100, this means that any JWT in the wild that specifies a mapping without an explicit value, relies on de default value to be understood as 100, so updating the library, and the server will make mappings that work basically stop messages.

[aricart]

Changed the implementation do do custom unmarshalling - if the weight option is not present the value will be 100 - this makes existing JWTs work as they did.

However, if new code is written that doesn't explicitly set the mapping value, the value will be 0, which means no traffic.
Only fix to this is lib release note or make some other API breaking change (either way it is breaking)

[aricart]

@kozlovic I am going to do a test to make sure that self-mappings actually work.

[kozlovic]

LGTM!

[aricart]

@kozlovic I am going to do a test to make sure that self-mappings actually work.

it does!

[aricart]

This is actually not going to work - the previous implementation relied on the fact that if the weight was not specified - defaulted to 0, the value was interpreted as 100, this means that any JWT in the wild that specifies a mapping without an explicit value, relies on de default value to be understood as 100, so updating the library, and the server will make mappings that work basically stop messages.

reworked.

[philpennock]

If someone has JSON exports to re-create a setup, this should work fine because either the weight is present and correct, or missing and 100, the old exports won't include a 0 weight because of the older omitempty semantics in Go.

If someone is creating weighted mappings from some other tooling, and they explicitly say 0 because it has previously been interpreted as 100%, that would now fail. So this is fine if there's a major number bump for a breaking change, but not as a patch-level change. I could succumb in a moment of weakness and accept a minor level change because it's a weird corner case.

Is there any way to look at the set of weighted mappings and say "if there's only one mapping, and it's 0%, then we interpret that as 100% unless and until there's a second mapping"? Or would that break because the server has different semantics and this is purely around how nsc models things?

Change itself looks sane, so approving.

[aricart]

That would invalidate the ability to self map to 0. It would require self map + one more perhaps at zero.

While the risk is there we can annotate. Or simply wait for server 3.0