Remove default WriteTimeout on server

[lucasmrod]

#22069

When performing GitOps with many pieces of software packages Fleet was terminating the connection after 100s thus not being able to use GitOps for software package management. The timeout depends on the number of software pieces + their size + how fast the server behind the URL serve the content + download speed of host running Fleet.

The 100 second timeout was only there for the synchronous live query APIs, but they are setting the timeout on the request:

fleet/server/service/live_queries.go

Lines 206 to 211 in adc7713

	// The period used here should always be less than the request timeout for any load
	// balancer/proxy between Fleet and the API client.
	period := os.Getenv("FLEET_LIVE_QUERY_REST_PERIOD")
	if period == "" {
	period = "25s"
	}

I will create a separate issue to address this the correct way, as the current one request approach is not optimal and some customers may find issues with it.

• Changes file added for user-visible changes in changes/, orbit/changes/ or ee/fleetd-chrome/changes.
  See Changes files for more information.
• Manual QA for all new/changed functionality

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 65.43%. Comparing base (ff01a87) to head (26ab8ca).
Report is 4 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #22146      +/-   ##
==========================================
+ Coverage   65.34%   65.43%   +0.08%     
==========================================
  Files        1493     1493              
  Lines      116651   116864     +213     
  Branches     3448     3448              
==========================================
+ Hits        76230    76466     +236     
+ Misses      33306    33287      -19     
+ Partials     7115     7111       -4     

Flag	Coverage Δ
backend	66.76% <ø> (+0.08%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[getvictor]

I looked into doing this a while back, and it looked like removing the timeout would be a security issue, since it would leave the server open to potential attacks. And even bad/buggy agent requests could block the server. https://stackoverflow.com/questions/77390547/why-shouldnt-i-set-http-writetimeout-to-0-none-in-my-go-server

I thought you were going to do the batch upload async, and have fleetctl check for results.

[lucasmrod]

I looked into doing this a while back, and it looked like removing the timeout would be a security issue, since it would leave the server open to potential attacks. And even bad/buggy agent requests could block the server. https://stackoverflow.com/questions/77390547/why-shouldnt-i-set-http-writetimeout-to-0-none-in-my-go-server

I thought you were going to do the batch upload async, and have fleetctl check for results.

Good point!

This was supposed to be a smaller fix so that 4.57.0 is not blocked by an async implementation being ready.
I was going to create a separate issue for fixing it the right way (async), but maybe #22069 is enough and we should do it the right way from get go (but not block the release on it).

I'll check with the product team. I'll close this and add docs around the WriteTimeout in our code.