Include `TEST_ENV_NUMBER` as part of file storage path in test environment

[mjankowski]

A few related changes:

• The paperclip initializer and CLI/media class have repeated logic about finding the file storage root path ... pull this out to a configuration.x... setting which they can then both use (would be happy to do this as stand-alone PR first if we want to eparate out the "consolidate config" aspect from the next item)
• When running in test env, include the Process.id value in the file storage root path -- I suspect this will fix some of the intermittent failures around things like media processing, directory cleanup, etc if my guess (that one process is cleaning up something while another is using it) is right there.

I believe that this preserves the non-test-env filesystem-based settings as before, which probably makes this relatively low risk (ie, if there are code paths which are in some way hard coding this path expectation and not relying on the config, they'd only break in test env?)

If this does not merge before the various open config_for PRs, we may want to rework this to move the setting into one of those themed around file storage vars.

[mjankowski]

Example failure - https://github.com/mastodon/mastodon/actions/runs/10474577117/job/29009317202

I realize now that this is going to fail all the end-to-end system specs on CI b/c the capybara server process and browser process are going to have different PIDs ... going to rework this to be based off ENV['TEST_ENV_NUMBER'] or something like that instead, which is a more direct mapping to the runner structure.

[mjankowski]

Updated to use env number instead, which does fix the system specs -- but we have a spot in the media CLI where both the spec and the implementation are very tightly coupled to the url style (doing status lookup by attachment url). Probably need a refactor of that area first before finding a non absurd way to do this.

Might pull out just the config/DRY refactor here ahead of that as well.

[ClearlyClaire]

I agree those flaky tests are most probably caused by flatware running the tests in parallel on the same file system.

I'm not completely happy with this change but I have no better solution.

Note that we also mess with the filesystem in spec/lib/mastodon/cli/emoji_spec.rb and spec/spec_helper.rb, although I think the rm_rf in the latter has been obsolete for a long time.

[mjankowski]

Yeah - I converted this to draft b/c I'm not happy with the current state of things (and some of the CLI specs/classes either need a refactor in advance of this or are going to become weird/brittle as side effect of doing this).

I'll try to chip away at the precursor stuff separately and then rebase/convert-to-ready this one when it's better.

[github-actions[bot]]

This pull request has merge conflicts that must be resolved before it can be merged.

[github-actions[bot]]

This pull request has resolved merge conflicts and is ready for review.