Better supports for Events API on FaaS

Description

Related to #361, I would like to introduce a new option to AppOptions in the next minor version or Bolt 2.

I would love to get you all’s suggestions for better naming but it is a flag to turn on/off the automatic Events API request acknowledgment. It allows developers to customize the behavior here: https://github.com/slackapi/bolt/blob/%40slack/bolt%401.5.0/src/App.ts#L474-L475

If we go with a name like autoEventAck, the default value is supposed to be true. If a developer set it as false, the app.event listener has ack function and it’s expected to call it for sure.

This is necessary to run Bolt apps safely on FaaS (Function-as-a-Service). Without this, Events API handlers may unexpectedly be terminated even while they’re still running.

What type of issue is this? (place an x in one of the [ ])

• bug
• enhancement (feature request)
• question
• documentation related
• testing related
• discussion

Requirements (place an x in each of the [ ])

• 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.
• I’ve searched for any related issues and avoided creating a duplicate issue.

[aoberoi]

My biggest concern is introducing an option for this behavior makes sample code, middleware, and documentation less portable. If some apps have the option set to the opposite of the default, they have to be very careful to comb through all their code to modify .event() listenerse (and middleware which operate on events) to do the right thing. In documentation, we’ll have to add caveats about this in many places.

I think the optionality will fragment our audience and increase our effort. Is that worth it?

Why can’t the FaaS implementation send responses after the event is fully processed (which it can in v2)? Even the .action() listeners who call ack() shouldn’t actually send the response until the event is fully processed. This alternate behavior can be full encapsulated in a Receiver implementation.

[seratch]

Agreed. The issue for the bug is #462 (for reference)