Make GetVersion more deterministic

[Quinn-With-Two-Ns]

Fix a possible source of non determinism in GetVersion calls. Since GetVersion can block on a future adding a call to it in a workflow can lead to non determinism so we need to avoid doing so in a backwards compatible way.

I tried to refactor the Version state machine to avoid ever blocking, but found the work too complicated for the benefit since due to backwards compatibility we can never remove the old state machine.

closes #1430

[cretz]

Suggested change

	public static SdkFlag GetValue(int _id) {
	SdkFlag[] As = SdkFlag.values();
	for (int i = 0; i < As.length; i++) {
	if (As[i].Compare(_id)) return As[i];
	}
	return SdkFlag.UNKNOWN;
	}
	public static Optional<SdkFlag> fromOrdinal(int ordinal) {
	if ordinal < 0 || ordinal >= SdkFlag.values().length - 1 {
	return Optional.empty();
	}
	return Optional.of(SdkFlag.values()[ordinal]);
	}

Might as well just resolve to always match the index and keep it optional instead of adding an unusable value to the class.

[cretz]

Why have an unknown flag? Just make the return from GetValue (sic) as Optional

[Quinn-With-Two-Ns]

UNKNOWN is not the same as an empty optional

[cretz]

What I'm saying is it shouldn't be the same. You should only have enumerates for real flags IMO. There's no reason to have all but one enumerate be a real flag IMO. Make it clear to the caller that the flag is unknown, not just that it happens to have another name.

[Quinn-With-Two-Ns]

I think returning UNKNOWN is clear to the caller that the flags meaning is not know. This is how we handle it in the other SDKs that implement flags as well

[cretz]

Eek. I hope we at least don't in TS, Python, and .NET. All those languages have a good way of representing an absent enum without having to work around that some values of the enum are representable in history and some aren't.

[Quinn-With-Two-Ns]

if it was an absent enum I would use optional, but it really is the lack of knowledge about how to handle a value. I would rather leave it as is in Java since I think it is clearer and more consistent with other SDKs.

[cretz]

I don't agree, but y'all's design choice here. At least it's internal.