mgmtapi: support deleting segments and beacons

[oncilla]

Support deleting segments and beacons via the management API of the control and daemon service. This is useful for cleaning up the databases (e.g., in case the issue mentioned in #4286 occurs)

---

This change is 

[lukedirtwalker]

Reviewed 25 of 25 files at r1, all commit messages.
Reviewable status: all files reviewed, 3 unresolved discussions (waiting on @matzf and @oncilla)

---

spec/control/beacons.yml line 125 at r1 (raw file):

        description: The segment ID of the beacon segment.
          If the input value is shorter than a segment ID, but matches the prefix of
          the segment ID of exactly one beacon, then this beacon is deleted.

hm but wouldn't the query delete all the matches? Why do we need that prefix behavior?

---

spec/control/beacons.yml line 131 at r1 (raw file):

        style: simple
        explode: false
      responses:

the implementation seems to also return 500, do we also need to list it here?

---

spec/segments/spec.yml line 86 at r1 (raw file):

        style: simple
        explode: false
      responses:

the implementation seems to also return 500, do we also need to list it here?

[jiceatscion]

Reviewed all commit messages.
Reviewable status: all files reviewed, 3 unresolved discussions (waiting on @matzf and @oncilla)

[matzf]

Would it make sense to add the same operations also for certs and trc databases?

Reviewed 3 of 25 files at r1.
Reviewable status: all files reviewed, 5 unresolved discussions (waiting on @oncilla)

---

private/storage/beacon/sqlite/db.go line 247 at r1 (raw file):

	e.Lock()
	defer e.Unlock()
	_, err := e.db.ExecContext(ctx, "DELETE FROM Beacons WHERE hex(SegID) LIKE ?", partialID+"%")

In the corresponding code in the path db, you use an explicit transaction. Here, in beacons db, the DeleteExpiredBeacons also uses a transaction. Is this not needed here?

---

spec/segments/spec.yml line 80 at r1 (raw file):

      parameters:
      - in: path
        name: segment-id

Document the prefix semantics for this too?

Note that get beacon does not support the prefix semantics...

[oncilla]

It would make sense, yes.
But I would prefer to do it in a separate PR.

Reviewable status: all files reviewed, 4 unresolved discussions (waiting on @lukedirtwalker and @matzf)

---

private/storage/beacon/sqlite/db.go line 247 at r1 (raw file):

Previously, matzf (Matthias Frei) wrote…

In the corresponding code in the path db, you use an explicit transaction. Here, in beacons db, the DeleteExpiredBeacons also uses a transaction. Is this not needed here?

It's technically not needed no. But for the sake of consistency, I added it here to.

---

spec/control/beacons.yml line 125 at r1 (raw file):

Previously, lukedirtwalker (Lukas Vogel) wrote…

hm but wouldn't the query delete all the matches? Why do we need that prefix behavior?

Thing is, we do not log the full ID, thus the prefix behavior.

Added a comment. But I'm on the fence. We could also drop the behavior.

---

spec/control/beacons.yml line 131 at r1 (raw file):

Previously, lukedirtwalker (Lukas Vogel) wrote…

the implementation seems to also return 500, do we also need to list it here?

Done.

---

spec/segments/spec.yml line 80 at r1 (raw file):

Previously, matzf (Matthias Frei) wrote…

Document the prefix semantics for this too?

Note that get beacon does not support the prefix semantics...

Done.

I'm pretty sure the beacon DB does support the prefix semantics:

scion/private/storage/beacon/sqlite/db.go

Line 254 in fce093e

subQ = append(subQ, "hex(SegID) LIKE (hex(?) || '%')")

---

spec/segments/spec.yml line 86 at r1 (raw file):

Previously, lukedirtwalker (Lukas Vogel) wrote…

the implementation seems to also return 500, do we also need to list it here?

Done.

[lukedirtwalker]

Reviewed 13 of 13 files at r2, all commit messages.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @matzf)

[matzf]

Reviewed 12 of 25 files at r1, 13 of 13 files at r2, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @oncilla)

---

spec/segments/spec.yml line 80 at r1 (raw file):

Previously, oncilla (Dominik Roos) wrote…

Done.

I'm pretty sure the beacon DB does support the prefix semantics:

scion/private/storage/beacon/sqlite/db.go

Line 254 in fce093e

subQ = append(subQ, "hex(SegID) LIKE (hex(?) || '%')")

Aha, thanks. I saw this, but was confused by the string concatenation operator it seems. 😅

[oncilla]

Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @oncilla)

---

spec/segments/spec.yml line 80 at r1 (raw file):

Previously, matzf (Matthias Frei) wrote…

Aha, thanks. I saw this, but was confused by the string concatenation operator it seems. 😅

Yeah, flash back to theoretical computer science. The only other place I know that uses || for string concatenation :)