Use OnceLock instead of manually implementing it

[arpad-m]

Problem

In #4743 , I'm trying to make more of the pageserver async, but in order for that to happen, I need to be able to persist the result of ImageLayer::load across await points. For that to happen, the return value needs to be Send.

Summary of changes

Use OnceLock in the image layer instead of manually implementing it with booleans, locks and Option.

Part of #4743

Checklist before requesting a review

• I have performed a self-review of my code.
• If it is a core feature, I have added thorough tests.
• Do we need to implement analytics? if so did you add the relevant metrics to the dashboard?
• If this PR requires public announcement, mark it with /release-notes label and add several sentences in this section.

Checklist before merging

• Do not forget to reformat commit message to not include the above checklist

[awestover]

looks like it simplified the code a bit! nice.

[github-actions]

1240 tests run: 1186 passed, 0 failed, 54 skipped (full report)

---

Flaky tests (7)

Postgres 15

• test_neon_cli_basics: release
• test_remote_storage_upload_queue_retries[local_fs]: release
• test_remote_timeline_client_calls_started_metric[local_fs]: release
• test_get_tenant_size_with_multiple_branches: release
• test_empty_tenant_size: release
• test_s3_wal_replay[local_fs]: debug

Postgres 14

• test_neon_cli_basics: release

[koivunej]

test_crafted_wal_end[last_wal_record_crossing_segment] is #4691 so re-running.

[koivunej]

Looking very good.

[arpad-m]

So so ok, we use OnceLock where possible and OnceCell where we need fallible init and it seems that is still waiting on decisions around Try on std.

Yeah, in the future we might have to switch some to OnceCell from tokio because that one also supports async init.

Personally I'm also good with consistently using OnceCell from once_cell, shrug.

[koivunej]

Personally I'm also good with consistently using OnceCell from once_cell, shrug.

Your call. I was hopeful of us no longer needing to use once_cell at all, but perhaps moving from it doesn't make sense if we cannot drop it as a dependency (which will probably never happen because of MSRV of our dependencies, realized only now). So maybe it was just a silly idea from me.

[arpad-m]

@koivunej yeah it will be years until the ecosystem switches off once_cell, even if the standard library catches up. I think it's best to not do the change for now, it's easy to do later in the future. We gain consistency and if someone does a refactor that requires a fallible init, they don't have to switch to once_cell.