Add built-in systemd notify support

[joaomarcos96]

Description

This PR aims to remove the need to install the sd_notify gem by vendoring its code, thus, making the support for systemd notify built-in.

I have considered what @mperham have done with Sidekiq and said about sd_notify #2438 (comment):

With Sidekiq I decided to vendor the code for the sd_notify gem because it's only ~50 lines of stable code. I didn't want to require the user to add the gem to their gemfile manually, that shouldn't be something they need to care about IMO.

Your checklist for this pull request

• I have reviewed the guidelines for contributing to this repository.
• I have added (or updated) appropriate tests if this PR fixes a bug or adds a feature. PS.: I haven't added tests as the sd_notify gem code was copied exactly as it is.
• My pull request is 100 lines added/removed or less so that it can be easily reviewed.
• If this PR doesn't need tests (docs change), I added [ci skip] to the title of the PR.
• If this closes any issues, I have added "Closes #issue" to the PR description or my commit messages.
• I have updated the documentation accordingly.
• All new and existing tests passed, including Rubocop.

[joaomarcos96]

I wasn't able to identify why there are some tests failing. Could someone help me with that?

[MSP-Greg]

Re the macOS failures, it looks like line 115 in test_integration_single.rb needs to change to:

assert_match(/Connection refused|Couldn't connect to server/, rejected_curl_stderr.read)

Or, the error message reported by curl has changed?

Let me check...

[joaomarcos96]

@MSP-Greg macOS-11 2.6 test is still failing. Any idea why?

[MSP-Greg]

macOS-11 2.6 test is still failing

Nothing to do with this PR. Intermittent test failure from hell.

I just noticed something re comments in sd_notify.rb. Most doc systems will attach the comments below require "socket" to the Puma namespace. So, they should probably be moved so they're below module Puma and indented. Doing so will attach them to Puma::SdNotify.

Maybe CI will pass...

[joaomarcos96]

@MSP-Greg thank you! I did what you suggested and now all tests are passing.
If this PR gets merged, I'd like the changes to be ported to 5.x as well. How could I do that? Should I open a PR for each 5.x-stable branch?

[dentarg]

I'm not sure how clear routines we have for backports (almost never happens in my experience) but https://github.com/puma/puma/tree/5-6-stable looks to be the same as https://github.com/puma/puma/releases/tag/v5.6.5 (I draw this conclusion from the release saying 139 commits to master since this release and the branch saying This branch is 23 commits ahead, 139 commits behind master. => both says 139 ✔️ 😄 – you may want to double check them)

Then there is this branch https://github.com/puma/puma/tree/5-6-5 This branch is 1 commit ahead, 77 commits behind master. not sure why it exist and if it serves any purpose

I think @nateberkopec can provide more guidance on backporting

[nateberkopec]

If this PR gets merged, I'd like the changes to be ported to 5.x as well. How could I do that? Should I open a PR for each 5.x-stable branch?

@joaomarcos96 Yes, that is correct. In this case though, because we're adding a feature, we should probably create a new minor version 5.7, so if you're still interested LMK and I will create a branch.

[joaomarcos96]

@nateberkopec Yes, I'd like that.

[nateberkopec]

👍 We now have a 5-7-stable branch, you may make PRs against it and we will release @joaomarcos96.

[voxik]

As a Fedora maintainer, I am disappointed with this PR and with bundling in general. What was the reason to not specify the dependency in .gemspec? If at least the code was put into dedicated directory to make this more obvious. And if at least the license field was updated to list the MIT license alongside the BSD-3-Clause.