CASSANDRA-20295 trunk fix min/max aggregation on reversed types

[smiklosovic]

Thanks for sending a pull request! Here are some tips if you're new here:

• Ensure you have added or run the appropriate tests for your PR.
• Be sure to keep the PR description updated to reflect all changes.
• Write your PR title to summarize what this PR proposes.
• If possible, provide a concise example to reproduce the issue for a faster review.
• Read our contributor guidelines
• If you're making a documentation change, see our guide to documentation contribution

Commit messages should follow the following format:

<One sentence description, usually Jira title or CHANGES.txt summary>

<Optional lengthier description (context on patch)>

patch by <Authors>; reviewed by <Reviewers> for CASSANDRA-#####

Co-authored-by: Name1 <email1>
Co-authored-by: Name2 <email2>

The Cassandra Jira

[dcapwell]

can you explain why this is needed vs returnType.unwrap()? If we are comparing we are just reversing the compare, so if we did returnType.unwrap() couldn't we avoid all this?

[dcapwell]

Suggested change

	assertRows(execute("SELECT count(b), min(b) as max FROM %s"),
	assertRows(execute("SELECT count(b), min(b) as min FROM %s"),

[dcapwell]

Suggested change

	assertRows(execute("SELECT count(b), min(b) as max FROM %s"),
	assertRows(execute("SELECT count(b), min(b) as min FROM %s"),

[dcapwell]

my main question is why the refactor doesn't do returnType.unwrap() and ignore all the complexity of reverse types. Im all for the refactor as i don't like copy/paste code, but the actual core part of the patch to address this I feel could be simplified, and mostly just wonder if there is a motivating reason to avoid .unwrap()?