Fix block element equality

[eamelink]

Summary

Block elements should be compared structurally, but their @EqualsAndHashCode annotation had callSuper = true. The super class however (typically ButtonElement) doesn't have equals overridden for structural equality. So two structurally identical elements would not be considered equal by .equals().

In other words, this was failing:

assertEquals(new ButtonElement(), new ButtonElement())

The first commit in this PR fixes that, by removing the callSuper = flag from the @EqualsAndHashCode annotation, so that these elements are considered equals when they are structurally equivalent.

Two additional commits that don't change anything, but just clean up a bit of code:

• First one removes @EqualsAndHashCode when there's already @Data, which includes that.
• Last one removes callSuper = false from the remaining @EqualsAndHashCode annotations, since it's the default value.

Requirements (place an x in each [ ])

• I've read and understood the Contributing Guidelines and have done my best effort to follow them.
• I've read and agree to the Code of Conduct.

[codecov]

Codecov Report

Merging #441 into master will increase coverage by 0.06%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master     #441      +/-   ##
============================================
+ Coverage     83.89%   83.95%   +0.06%     
- Complexity     2369     2370       +1     
============================================
  Files           250      250              
  Lines          6376     6376              
  Branches        578      578              
============================================
+ Hits           5349     5353       +4     
+ Misses          673      669       -4     
  Partials        354      354              

Impacted Files	Coverage Δ	Complexity Δ
...i/bolt/context/builtin/BlockSuggestionContext.java	100.00% <ø> (ø)	3.00 <0.00> (ø)
...slack/api/bolt/context/builtin/DefaultContext.java	100.00% <ø> (ø)	1.00 <0.00> (ø)
.../bolt/context/builtin/DialogSubmissionContext.java	0.00% <ø> (ø)	0.00 <0.00> (ø)
.../bolt/context/builtin/DialogSuggestionContext.java	100.00% <ø> (ø)	3.00 <0.00> (ø)
.../api/bolt/context/builtin/SlashCommandContext.java	60.00% <ø> (ø)	6.00 <0.00> (ø)
...pi/bolt/context/builtin/ViewSubmissionContext.java	77.77% <ø> (ø)	13.00 <0.00> (ø)
...in/java/com/slack/api/audit/AuditApiException.java	72.72% <ø> (ø)	6.00 <0.00> (ø)
.../slack/api/methods/MethodsCompletionException.java	100.00% <ø> (ø)	2.00 <0.00> (ø)
.../java/com/slack/api/methods/SlackApiException.java	63.63% <ø> (ø)	5.00 <0.00> (ø)
...main/java/com/slack/api/scim/SCIMApiException.java	72.72% <ø> (ø)	6.00 <0.00> (ø)
... and 4 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a14cb63...540024d. Read the comment docs.

[seratch]

@eamelink Great catch! (yes, this is my fault...) Thank you very much for your contribution 🙇

[seratch]

@eamelink I've overlooked this but having @EqualsAndHashCode(callSuper=false) was intentional. You should see the following warnings by Lombok. Let me revert this commit: 41294ce

/java-slack-sdk/slack-api-client/src/main/java/com/slack/api/scim/response/UsersReadResponse.java:7: warning: Generating equals/hashCode implementation but without a call to superclass, even though this class does not extend java.lang.Object. If this is intentional, add '@EqualsAndHashCode(callSuper=false)' to your type.
@Data
^